ICE in incr comp after s/trait/struct/: src/librustc/dep_graph/graph.rs:688: DepNode Hir(...) should have been pre-allocated but wasn't.

[progval]

Hi,

I just got a crash on Travis, on stable (1.35.0), when enabling edition="2018"

Commands ran by Travis:

git clone https://github.com/fflorent/nom_locate.git
cd nom_locate
git checkout -qf 77e08c3bfb1cadee8176f96ea78ba8c68308d9c8
cargo build --no-default-features --features=""
cargo test --no-default-features --features=""

which causes this output:

    Updating crates.io index
   Compiling nom_locate v0.3.1 (/home/travis/build/fflorent/nom_locate)
    Finished dev [unoptimized + debuginfo] target(s) in 0.47s
   Compiling nom_locate v0.3.1 (/home/travis/build/fflorent/nom_locate)
error: internal compiler error: src/librustc/dep_graph/graph.rs:688: DepNode Hir(nom_locate[4d08]::tests[0]::it_should_capture_position[1]::{{misc}}[4]::{{misc}}[0]) should have been pre-allocated but wasn't.
thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:635:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.35.0 (3c235d560 2019-05-20) running on x86_64-unknown-linux-gnu
note: compiler flags: -C debuginfo=2 -C incremental
note: some of the compiler flags provided by cargo are hidden

But I can't reproduce this on my computer.

Link to the Travis log: https://travis-ci.org/fflorent/nom_locate/jobs/558169389

[hellow554]

Cannot reproduce with local 1.35.0. Build passes with the exact same compiler, git commit and command line. Maybe something travis specific? Can you try to upgrade to the latest 1.36.0 and see if it still happens?

[progval]

It works on 1.36.0-beta.7 on travis: https://travis-ci.org/fflorent/nom_locate/jobs/558169394

[jonas-schievink]

@progval does this happen even after clearing the Travis cache?

[progval]

That fixed it.

Should I close the issue?

[jonas-schievink]

No, that means it's an incremental compilation bug. Finding a way to reproduce this would be good.

[nasso]

I just got the same error on my project, and I am able to reproduce it first building on a first commit and then immediately building again on the next commit.

I am going to try to make an MCVE but if anyone wants to try this right now, here's the repo and the relevant commits (of course anyone is allowed to use this to create an MCVE or fix the bug in some other way):
Repo: https://github.com/nasso/screensnap
First commit (build from scratch from there): nasso/screensnap@6e1e327
Second commit (checkout that commit and trigger an incremental build from the previous one): nasso/screensnap@56a104e

Here's what rustc gives me:

error: internal compiler error: src\librustc\dep_graph\graph.rs:688: DepNode Hir(screensnap[29a7]::screengrab[0]::Screenshot[0]::data[0]) should have been pre-allocated but wasn't.

thread 'rustc' panicked at 'Box<Any>', src\librustc_errors\lib.rs:637:9
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to previous error


note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.36.0 (a53f9df32 2019-07-03) running on x86_64-pc-windows-gnu

note: compiler flags: -C debuginfo=2 -C ar=D:\Programmes\msys64\mingw64\bin\ar.exe -C linker=D:\Programmes\msys64\mingw64\bin\gcc.exe -C incremental --crate-type bin

note: some of the compiler flags provided by cargo are hidden

error: Could not compile `screensnap`.

Now I'm going to try to find a simpler way to reproduce it, but I'm leaving this here in case I wasn't able to.

Edit: see my message below

[nasso]

Okay I got it:

1. Create a new library crate (this way unused stuff doesn't get optimized out): cargo new --lib test
2. Create a public trait with a function named foo:

pub trait Something {
    fn foo();
}

3. cargo build
4. Change the trait to a structure (keeping the same name), and the function to a field (with the same name too). I don't think the type matters but I haven't tried with different types:

pub struct Something {
    foo: u8,
}

5. cargo build again; here the error shows up for me.

[hellow554]

Can confirm the mcve above! 🎉

// revisions: rpass1 rpass2

#[cfg(rpass1)]
pub trait Something {
    fn foo();
}

#[cfg(rpass2)]
pub struct Something {
    pub foo: u8, 
}

fn main() {}

[hellow554]

Regression in nightly-2019-05-06 (looking for the exact commit)
regression in d65e721

CC #60525 @eddyb

@rustbot modify labels: -E-needs-bisection

[eddyb]

You have to be kidding me. Just from #60525 causing a regression, we can tell that:

• trait Something's method foo
• struct Something's field foo

used to have different DefPaths but don't after that PR.

Now they're both {type:Something}::{value:foo}. But there should exist examples of DefPath collisions before #60525, I don't think I introduced the only ones that cause this bug.

Probably the simplest thing to try is changing a method to an associated constant.
Or even a free function and a const. I'll report back if I find another testcase.

EDIT: I can't get those to trigger an ICE, traits might be special :(.

[eddyb]

cc @Zoxc @michaelwoerister Any idea how matching DefPaths can cause an ICE? AFAIK you would still have the different HIR, which would result in the old query results being discarded.

[nikomatsakis]

Compiler team triage:

Marking as P-high as this is some sort of regression. No assignee yet.

[zekun000]

Hi, I'm affected by this too, I saw from comment it's related to incremental build. What command should I use to workaround this?

[hellow554]

Use cargo clean when you encounter it. It should not happen unless you change something between builds. Or you could disable incremental compilation

[fanninpm]

In my efforts to add things to the glacier, I couldn't get the MVCE to ICE on the latest nightly.

[frapa]

Just wanted to confirm it again by renaming of trait to struct with rustc 1.41.0 (5e1a799 2020-01-27)

[ocstl]

Triage: Since this has been fixed and is covered by a regression test, is it still relevant to keep open?

[jackh726]

Going to close as fixed with test.