internal compiler error: debuginfo::create_for_loop_var_metadata()

[Kintaro]

src/config.rs:74:9: 74:10 error: internal compiler error: debuginfo::create_for_loop_var_metadata() - Referenced variable location is not an alloca!
src/config.rs:74     for i in range(1u, 10) {

Happens with the latest commit (34d6800)

[vhbit]

Looks like it was introduced in #20027

[Aatch]

cc @michaelwoerister

[japaric]

Minimal script to reproduce

// for.rs
fn main() {
    for i in range(0, 10i) {}
}

$ rustc -g for.rs
for.rs:3:9: 3:10 error: internal compiler error: debuginfo::create_for_loop_var_metadata() - Referenced variable location is not an alloca!
for.rs:3     for i in range(0, 10i) {}
                 ^
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:123

stack backtrace:
   1:     0x7f15831987f0 - sys::backtrace::write::hc1f09f1eae19d77aQxt
   2:     0x7f15831b9710 - failure::on_fail::h0fb87b850ab6cd900Xz
   3:     0x7f15831254a0 - rt::unwind::begin_unwind_inner::habde574b4f76ade20Bz
   4:     0x7f157e1c6f00 - rt::unwind::begin_unwind::h16328291673998487577
   5:     0x7f157e1c6e80 - diagnostic::SpanHandler::span_bug::hbb7934a78e265d5dSXF
   6:     0x7f15810a0350 - session::Session::span_bug::h8e056d7b667a2fcb1on
   7:     0x7f15820272a0 - middle::pat_util::pat_bindings::closure.49058
   8:     0x7f157e191d50 - ast_util::walk_pat::hab0b8805a667994dlxC
   9:     0x7f1581f54f90 - trans::expr::trans_rvalue_stmt_unadjusted::hb3ffc0f604cb73e4l4i
  10:     0x7f1581f0f2c0 - trans::expr::trans_into::h71668aa506e1a690uGh
  11:     0x7f1581f0fa20 - trans::controlflow::trans_block::hc167a4817215f70d9Zd
  12:     0x7f1581fbb310 - trans::base::trans_closure::h0f21c829c37744a86au
  13:     0x7f1581f03fd0 - trans::base::trans_fn::h5a95a6b70c2d9335nmu
  14:     0x7f1581eff520 - trans::base::trans_item::hf517e1dbb2128044rHu
  15:     0x7f1581fc3230 - trans::base::trans_crate::he5a814094c8a4da1HDv
  16:     0x7f15836f8f70 - driver::phase_4_translate_to_llvm::hc65b794b160978481Ca
  17:     0x7f15836cfe40 - driver::compile_input::hec1a59cac622cf55vba
  18:     0x7f1583877220 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h10851168864564136615
  19:     0x7f15838758d0 - rt::unwind::try::try_fn::h10692001439554181982
  20:     0x7f158321d3f0 - rust_try_inner
  21:     0x7f158321d3e0 - rust_try
  22:     0x7f1583875c00 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h18028200319240022992
  23:     0x7f15831a8f60 - sys::thread::thread_start::hdeb95f039f29863doww
  24:     0x7f157d9c9250 - start_thread
  25:     0x7f1582ddb219 - clone
  26:                0x0 - <unknown>

@alexcrichton Don't we run test with debuginfo enabled? I find surprising that bors didn't catch this ICE.

[alexcrichton]

I've reverted #20027 in #20132

[michaelwoerister]

I'm looking into right now. While we do have quite a few test cases containing for-loops, none of them seems to be without destructuring, which triggers a slightly different trans path...

[michaelwoerister]

OK, so the problem is that for the non-destructuring case the value of the iteration variable isn't copied out into its own alloca -- instead we just have the result of a GEPi instruction. That's something that LLVM debuginfo doesn't like, hence the check that tears down rustc now.
There are two ways to fix this:
(1) Disable the trans 'fast path' in _match::store_for_loop_binding if debuginfo level is 2.
(2) Make a 'complex variable' debuginfo description that knows how to compute the position of the iteration variable value within its wrapping Option instance.

I prefer option (2) because it's a bit cleaner and doesn't clutter the IR when debuginfo is enabled. But it's also a bit more work and since bors is already munching on the revert-commit and my wife wants me to be already munching on my dinner, I'll implement the fix tomorrow and make another pull request then...

[alexcrichton]

No rush @michaelwoerister, thanks for taking the time to investigate!

[carllerche]

I don't think that the revert fixed it. I am running off of 34d6800 and am still hitting the ICE.

[HeroesGrave]

@carllerche: I believe that's the commit that merged the bug. It was reverted in 2f3cff6

[carllerche]

@HeroesGrave Yeah sorry. It seems like I failed at git

[alexcrichton]

Fixed in #20132.

[devilbuddy]

how soon is there a new nightly after this fix? (current one still failing for me..)

[Aatch]

@devilbuddy a few hours

[heyman]

I'm running into this issue as well.
Slightly off topic, but is there a way to install yesterday's - or some other day's - nightly build? (I started learning rust just a few days ago).

[badboy]

@heyman Some are archived, see http://www.reddit.com/r/rust/comments/2p9ekl/does_anyone_archive_the_nightly/. Sadly, I didn't find an index

[tomaka]

New Linux nightlies have been released, Windows probably too.

[John-Nagle]

cargo build
Compiling safety_tests v0.0.1 (file:///home/john/projects/rustcode/safety_tests)
/home/john/projects/rustcode/safety_tests/src/main.rs:38:9: 38:10 error: internal compiler error: debuginfo::create_for_loop_var_metadata() - Referenced variable location is not an alloca!
/home/john/projects/rustcode/safety_tests/src/main.rs:38 for r in rpts.iter() {
^
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with RUST_BACKTRACE=1 for a backtrace
thread 'rustc' panicked at 'Box', /home/rustbuild/src/rust-buildbot/slave/nightly-linux/build/src/libsyntax/diagnostic.rs:123

stack backtrace:
1: 0x7feac0eea7f0 - sys::backtrace::write::hc1f09f1eae19d77aQxt
2: 0x7feac0f0b710 - failure::on_fail::h0fb87b850ab6cd900Xz
3: 0x7feac0e774a0 - rt::unwind::begin_unwind_inner::habde574b4f76ade20Bz
4: 0x7feabbef5f00 - rt::unwind::begin_unwind::h16328291673998487577
5: 0x7feabbef5e80 - diagnostic::SpanHandler::span_bug::hbb7934a78e265d5dSXF
6: 0x7feabedcf350 - session::Session::span_bug::h8e056d7b667a2fcb1on
7: 0x7feabfd562a0 - middle::pat_util::pat_bindings::closure.49058
8: 0x7feabbec0d50 - ast_util::walk_pat::hab0b8805a667994dlxC
9: 0x7feabfc83f90 - trans::expr::trans_rvalue_stmt_unadjusted::hb3ffc0f604cb73e4l4i
10: 0x7feabfc3e2c0 - trans::expr::trans_into::h71668aa506e1a690uGh
11: 0x7feabfc3ea20 - trans::controlflow::trans_block::hc167a4817215f70d9Zd
12: 0x7feabfcea310 - trans::base::trans_closure::h0f21c829c37744a86au
13: 0x7feabfc32fd0 - trans::base::trans_fn::h5a95a6b70c2d9335nmu
14: 0x7feabfc2e520 - trans::base::trans_item::hf517e1dbb2128044rHu
15: 0x7feabfcf2230 - trans::base::trans_crate::he5a814094c8a4da1HDv
16: 0x7feac144af70 - driver::phase_4_translate_to_llvm::hc65b794b160978481Ca
17: 0x7feac1421e40 - driver::compile_input::hec1a59cac622cf55vba
18: 0x7feac15c9220 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h10851168864564136615
19: 0x7feac15c78d0 - rt::unwind::try::try_fn::h10692001439554181982
20: 0x7feac0f6f3f0 - rust_try_inner
21: 0x7feac0f6f3e0 - rust_try
22: 0x7feac15c7c00 - thunk::F.Invoke<A,$u{20}R$GT$::invoke::h18028200319240022992
23: 0x7feac0efaf60 - sys::thread::thread_start::hdeb95f039f29863doww
24: 0x7feabb6f70c0 - start_thread
25: 0x7feac0b1cec9 - __clone
26: 0x0 -
Could not compile safety_tests.

As in the other bug reports, this appears to be related to a FOR loop.

---

Broken in:
rustc 0.13.0-nightly (34d6800 2014-12-22 00:12:47 +0000)

Fixed in:
rustc 0.13.0-nightly (96a3c7c 2014-12-23 22:21:10 +0000)

[THeK3nger]

If it helps, I can add my stackstrace:

C:\Users\Davide\Dropbox\Code\CellularMaps-Rust\src\main.rs:6    for c in range(0u,(map.get_width())) {
                                                                    ^
C:\Users\Davide\Dropbox\Code\CellularMaps-Rust\src\main.rs:6:6: 6:7 error: internal compiler error: debuginfo::create_for_loop_var_metadata() - Referenced variable location is not an alloca!
C:\Users\Davide\Dropbox\Code\CellularMaps-Rust\src\main.rs:6    for c in range(0u,(map.get_width())) {
                                                                    ^
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: http://doc.rust-lang.org/complement-bugreport.html
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', C:\bot\slave\nightly-win-64\build\src\libsyntax\diagnostic.rs:123

stack backtrace:
   1:         0x69bef7f8 - sys::backtrace::write::h5b0ba28ad71857afeQt
   2:         0x69c021e9 - rt::unwind::register::h91aefd9b472076aecGz
   3:         0x69b82fcb - rt::unwind::begin_unwind_inner::h04b772eae7a7fc7bJDz
   4:         0x6f8acd56 - diagnostic::SpanHandler::span_bug::h90408fcd1499494fwZF
   5:         0x6f8acd00 - diagnostic::SpanHandler::span_bug::h90408fcd1499494fwZF
   6:           0x4a1cea - session::Session::span_bug::h33a792ccd13ce896fon
   7:           0xf7cecf - trans::debuginfo::UniqueTypeId...std..fmt..Show::fmt::h2a94dd8eb7abda200OD
   8:         0x6f8791e1 - ast_util::walk_pat::h6509451e2c595f07fyC
   9:           0xeb1553 - trans::type_::Type...std..cmp..PartialEq::ne::h4b92644f40b08c44S1J
  10:           0xe6a133 - trans::cleanup::FunctionContext<$u{27}blk$C$$u{20}$u{27}tcx$GT$.CleanupMethods$LT$$u{27}blk$C$$u{20}$u{27}tcx$GT$::pop_and_trans_ast_cleanup_scope::h411a754a1c1fd541h4K
  11:           0xe6aa68 - trans::cleanup::FunctionContext<$u{27}blk$C$$u{20}$u{27}tcx$GT$.CleanupMethods$LT$$u{27}blk$C$$u{20}$u{27}tcx$GT$::pop_and_trans_ast_cleanup_scope::h411a754a1c1fd541h4K
  12:           0xf158ec - trans::base::IsUnboxedClosureFlag...std..clone..Clone::clone::h57e6afe7886161b1abu
  13:           0xe5ec48 - trans::context::CrateContext<$u{27}b$C$$u{20}$u{27}tcx$GT$::sess::hcfd66e5fd92d5809Ksm
  14:           0xe5a40e - trans::context::CrateContext<$u{27}b$C$$u{20}$u{27}tcx$GT$::stats::h05a9b3c7687a7fcemFm
  15:           0xf1c578 - trans::base::trans_crate::h397f6c9d3999aac9aEv
  16:         0x70b2d263 - driver::phase_4_translate_to_llvm::h3d4d3b1fa1113efa1Ca
  17:         0x70b03b22 - driver::compile_input::hd01226bf772688afvba
  18:         0x70ca3e95 - run::h9cdc49dc8c011aeedYb
  19:         0x70ca05b9 - run::h9cdc49dc8c011aeedYb
  20:         0x69c6648c - rust_try
  21:         0x69c66469 - rust_try
  22:         0x70ca0d0f - run::h9cdc49dc8c011aeedYb
  23:         0x69bf4ee7 - sys::tcp::TcpListener::bind::hb1b42652ff0a60d9Fqw
  24:     0x7ffcd12516ad - BaseThreadInitThunk

Could not compile `cellular_maps`.

Rust version is

$ rustc --version
rustc 0.13.0-nightly (34d680009 2014-12-22 00:12:47 +0000)

and the code I'm trying to compile is

extern crate cellular_maps;

use cellular_maps::CellularMap;

fn print_map(map: &CellularMap) {
    for c in range(0u,(map.get_width())) {
        println!("{} {}",c);
    }
}

fn main() {
    let cm = CellularMap::new(12u,12u,10u);
    print_map(&cm);
}

[THeK3nger]

Sorry, my bad. With the last nightly my error seems solved.