regression: stack overflow on macosx with xcode 6.4

[gnzlbg]

The build.rs of mach-test in the mach crate commit fitzgen/mach@d31c809 crashes on MacOS X with a stack overflow when xcode 6.4 is used. This used to work, but is now failing on nightly, so this stack overflow is a regression. I don't have access to a MacOSX system with xcode 6.4 but travis reproduces this reliably. The PR in mach that works around this is: fitzgen/mach#49

[alexcrichton]

This is showing up in curl-rust as well -- alexcrichton/curl-rust#234

(I haven't reproduced it myself yet)

[alexcrichton]

cc @oli-obk, the stack trace in the curl issue looks like const eval things?

[oli-obk]

You mean because of the mir_const query call? That's a normal step in any compilation. It's just the MIR that const eval needs to run on. It will continue to get processed later, but it's already the regular MIR that you will get for any function.

[alexcrichton]

er sorry I apologize, I misremembered the stack trace as being const related when in fact it's simply MIR construction related. My bad!

[oli-obk]

No worries. I'm knee deep in Mir building code right now anyway, I'll build a repro that I can run on x86 and see what it takes to remove a few intermediate stack frames or locals.

[oli-obk]

Actually, we might want to fix this once and forever. I think we can change the recursion into a loop (well obviously, but I mean without making the code impossible to maintain). Cc @rust-lang/compiler do you think it's reasonable to attempt refactoring Mir building code to use stacks or should we patch this over and wait for guaranteed TCO?

[nagisa]

We already have an outstanding issue to reduce the default stack size from 16MB back to 8MB (upping the stack to 16MB was a temporary-not-temporary workaround to a similar issue). Compiler should not restrict itself with code down to the fairly arbitrarily chosen size of the compiler’s stack.

[nagisa]

That being said I do not believe it is sensible to single-out the MIR building code – there are quite a few other areas that are implemented recursively and could be problematic. I feel that we should simply implement some sort of dynamic stack sizing functionality for rustc. I don’t think it is necessary to make it able to reduce the stack – only increasing when the stack limit is reached ought to be fine IMO.

[emilyalbini]

Does this happen on beta?

[gnzlbg]

Does this happen on beta?

Yes, I've modified mach CI to test that, and it produces a stack overflow in beta as well: https://travis-ci.org/gnzlbg/mach/builds/448907619