ICE: 'lookup_item: id not found: 102830'

[jeaye]

┌─[jeaye@arrow]─[~/projects/q3][i19]
└──╼ RUST_LOG=rustc=1 make
»»» Building DEBUG Q³ [commit: db34ba0](this can take a while)

task <unnamed> failed at 'lookup_item: id not found: 102830', /build/rust-git/src/rust/src/librustc/metadata/decoder.rs:92
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
task <unnamed> failed at 'explicit failure', /build/rust-git/src/rust/src/librustc/rustc.rs:377
make: *** [debug] Error 101

I'm not sure yet what's causing this; it showed up after updating Rust (which I do daily with strcat's nightly Arch builds). I've done clean builds, rebuilt all my submodules, and stashed any changes. This is a regression.

See #5862

Package information:
Running rust-git-0.7.2649.gb81743e-1-x86_64 I get the ICE. After downgrading to the previous build rust-git-0.7.2590.gc8f69dd-1-x86_64 the ICE is gone.

[emberian]

cc @nikomatsakis: I think this is related to your AST renaming patch, this is the bug I hit with rustdoc_ng and then accidentally wiped my working tree.

[nikomatsakis]

@jeaye does this ICE occur building rust, or some other project?

[jeaye]

@nikomatsakis This occurs when building [1]q3 (from a clean build and
cleaning and rebuilding all submodules, too).

Switching between the two above nightly builds of Rust enable/disable
the problem, so it must be a change that went in that day.

[1] https://github.com/Jeaye/q3

On Thu, Sep 19, 2013 at 02:58:33AM -0700, Niko Matsakis wrote:

[1]@jeaye does this ICE occur building rust, or some other project?

—
Reply to this email directly or [2]view it on GitHub.
[HsRVgEn5y14gQ9FgbvZPHqZmwMSqOErwgV17Nhnu8mie7mlWsqa7b6m05w8UOwhe.gif]

References

1. https://github.com/jeaye
2. ICE: 'lookup_item: id not found: 102830' #9189 (comment)

[jeaye]

I spent some time (and unfortunately some of Niko's) looking into this to find that a clean build was not as clean as I'd thought. The reason for this is that glfw-rs, which builds using rustpkg changed its path for the outputted binary. My insufficient error checking made it so that executions of ./configure in q3 just kept the existing glfw-rs around. This means that it's the ol' binary incompatability ICE with a bit of extra confusion on top. I updated my configure script here ( jeaye/q3@cd238a2 ) to properly copy based on the new path that rustpkg gives and the problem is resolved.

Sorry for asserting I was properly cleaning when I was not (lesson learned -- always test on a clean clone).

EDIT:
To answer the question of (why was it working with the previous commit?): I had to update glfw-rs when I updated Rust, since some changes went in. This had a side effect of bringing the new build path from rustpkg. What broke it was updating glfw-rs and not being prepared for a path change.