Stack overflow when compiling lots of macros

[Toby-S]

The code in this (large) gist causes a stack overflow using the current nightly (detailed below):

rustc 1.6.0-nightly (8ca0acc25 2015-10-28)
binary: rustc
commit-hash: 8ca0acc25adb00d29e52b015bded4b2872a1170c
commit-date: 2015-10-28
host: x86_64-unknown-linux-gnu
release: 1.6.0-nightly

This works as expected on stable and beta. On nightly, it prints the following:

thread 'rustc' has overflowed its stackSegmentation fault

gdb backtrace:

#0  0x00007ffff65338d6 in build::expr::as_operand::_$LT$impl$GT$::expr_as_operand::h9c1451c0620ac356CQa () from glibrustc_mir-8cf6ce90.so
#1  0x00007ffff6536c8b in build::expr::as_rvalue::_$LT$impl$GT$::expr_as_rvalue::h14d54ba4a836663bmCa () from glibrustc_mir-8cf6ce90.so
#2  0x00007ffff6540a32 in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#3  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#4  0x00007ffff6540fde in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#5  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#6  0x00007ffff65302ae in build::into::_$LT$impl$GT$::eval_into::he93472f166794e5e8pb () from glibrustc_mir-8cf6ce90.so
#7  0x00007ffff652e829 in build::block::_$LT$impl$GT$::ast_block::h2fd32d2e4e14cf99Wka () from glibrustc_mir-8cf6ce90.so
#8  0x00007ffff6542d81 in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#9  0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#10 0x00007ffff6540fde in build::expr::into::_$LT$impl$GT$::into_expr::h6344e65068aab977g8a () from glibrustc_mir-8cf6ce90.so
#11 0x00007ffff6545dff in build::into::_$LT$impl$GT$::eval_into::h06f1417250413589Tob () from glibrustc_mir-8cf6ce90.so
#12 0x00007ffff6556421 in build::matches::_$LT$impl$GT$::expr_into_pattern::ha79c7de5a782ab45yUb () from glibrustc_mir-8cf6ce90.so
#13 0x00007ffff655c5f7 in build::stmt::_$LT$impl$GT$::stmt::h6613d503c10a36cdvSc () from glibrustc_mir-8cf6ce90.so
#14 0x00007ffff653018f in build::stmt::_$LT$impl$GT$::stmts::he98a9d97d5640b65RRc () from glibrustc_mir-8cf6ce90.so

... repeated a fair few times ...

#6497 0x00007ffff655dd5d in build::stmt::_$LT$impl$GT$::stmt::h6613d503c10a36cdvSc () from glibrustc_mir-8cf6ce90.so
#6498 0x00007ffff653018f in build::stmt::_$LT$impl$GT$::stmts::he98a9d97d5640b65RRc () from glibrustc_mir-8cf6ce90.so
#6499 0x00007ffff652e7ca in build::block::_$LT$impl$GT$::ast_block::h2fd32d2e4e14cf99Wka () from glibrustc_mir-8cf6ce90.so
#6500 0x00007ffff652a33e in build::construct::ha182b6bb92aa06f5Xba () from glibrustc_mir-8cf6ce90.so
#6501 0x00007ffff6562302 in mir_map::_$LT$impl$GT$::visit_fn::h9d61a6d7b3adc6e8a1c () from glibrustc_mir-8cf6ce90.so
#6502 0x00007ffff6560af9 in mir_map::_$LT$impl$GT$::visit_item::h6d489316c8636cd2aYc () from glibrustc_mir-8cf6ce90.so
#6503 0x00007ffff656004c in mir_map::build_mir_for_crate::hb6d45ba511f84ea1iWc () from glibrustc_mir-8cf6ce90.so
#6504 0x00007ffff7a525ad in driver::phase_3_run_analysis_passes::_$LT$closure$GT$::closure.21965 () from glibrustc_driver-8cf6ce90.so
#6505 0x00007ffff7a35d84 in middle::ty::context::_$LT$impl$GT$::create_and_enter::create_and_enter::h18093044235211963808 ()
   from glibrustc_driver-8cf6ce90.so
#6506 0x00007ffff7a30d7f in driver::phase_3_run_analysis_passes::h230269733980357556 () from glibrustc_driver-8cf6ce90.so
#6507 0x00007ffff7a117f3 in driver::compile_input::hc3d55c2eb88ab4bd8ba () from glibrustc_driver-8cf6ce90.so
#6508 0x00007ffff7b6851c in run_compiler::h0799634305b54a4dvqc () from glibrustc_driver-8cf6ce90.so
#6509 0x00007ffff7b65597 in sys_common::unwind::try::try_fn::try_fn::h9960778850285224810 () from glibrustc_driver-8cf6ce90.so
#6510 0x00007ffff757a739 in __rust_try () from glibstd-8cf6ce90.so
#6511 0x00007ffff756e78c in sys_common::unwind::try::inner_try::h39e356f8934d9b5cwds () from glibstd-8cf6ce90.so
#6512 0x00007ffff7b658e5 in boxed::_$LT$impl$GT$::call_box::call_box::h8909761637860690051 () from glibrustc_driver-8cf6ce90.so
#6513 0x00007ffff7581db4 in sys::thread::_$LT$impl$GT$::new::thread_start::h85eb4d682b5d5d4ffGw () from glibstd-8cf6ce90.so
#6514 0x00007ffff0c3f0a4 in start_thread (arg=0x7fffeebff700) at pthread_create.c:309
#6515 0x00007ffff720404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

[Manishearth]

Looks like we should be looping instead of recursing here?

cc @nrc

[durka]

This is also a regression (the code compiles on stable and beta).

[nrc]

cc @nikomatsakis looks like a mir problem? I guess the macros thing is just a way to construct the problematic code?

[nikomatsakis]

I agree this is caused by MIR construction. The macro seems kind of irrelevant.

[nikomatsakis]

I think the cause is that each let introduces a new scope, and the MIR construction code recurses as we walk down those scopes. One possible fix would be to avoid recursion, but that might also be a bit tricky. Have to go look. Another option might be to employ the ability to grow the stack --- @alexcrichton you made some crate that lets you insert manual stack checks (and grow stack as needed), right? In general this might be a useful thing at various points in the compiler, where recursion can be so natural.

[nikomatsakis]

Relevant discussion thread: https://internals.rust-lang.org/t/supporting-infinite-recursion-via-stacker/2863

[nikomatsakis]

triage: P-high

This is a (Nightly-only) regression, so it's got to be fixed.