Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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. #62649

Closed
progval opened this issue Jul 13, 2019 · 44 comments · Fixed by #68289
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@progval
Copy link
Contributor

progval commented Jul 13, 2019

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

@estebank estebank added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 14, 2019
@jonas-schievink jonas-schievink added C-bug Category: This is a bug. I-nominated labels Jul 14, 2019
@hellow554
Copy link
Contributor

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
Copy link
Contributor Author

progval commented Jul 15, 2019

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

@jonas-schievink
Copy link
Contributor

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

@progval
Copy link
Contributor Author

progval commented Jul 18, 2019

That fixed it.

Should I close the issue?

@jonas-schievink jonas-schievink added the A-incr-comp Area: Incremental compilation label Jul 18, 2019
@jonas-schievink
Copy link
Contributor

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

@jonas-schievink jonas-schievink added the E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example label Jul 18, 2019
@nasso
Copy link
Contributor

nasso commented Jul 25, 2019

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
Copy link
Contributor

nasso commented Jul 25, 2019

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();
}
  1. cargo build
  2. 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,
}
  1. cargo build again; here the error shows up for me.

@hellow554
Copy link
Contributor

hellow554 commented Jul 25, 2019

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() {}

@rustbot rustbot added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc and removed E-needs-mcve Call for participation: This issue has a repro, but needs a Minimal Complete and Verifiable Example labels Jul 25, 2019
@hellow554
Copy link
Contributor

hellow554 commented Jul 25, 2019

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

CC #60525 @eddyb

@rustbot modify labels: -E-needs-bisection

@rustbot rustbot added E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc and removed E-needs-bisection Call for participation: This issue needs bisection: https://github.com/rust-lang/cargo-bisect-rustc labels Jul 25, 2019
@eddyb
Copy link
Member

eddyb commented Jul 25, 2019

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
Copy link
Member

eddyb commented Jul 25, 2019

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 nikomatsakis added P-high High priority and removed I-nominated labels Jul 25, 2019
@nikomatsakis
Copy link
Contributor

Compiler team triage:

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

@zekun000
Copy link

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
Copy link
Contributor

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

@fanninpm
Copy link

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

@frapa
Copy link

frapa commented May 23, 2020

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

bors added a commit to rust-lang-ci/rust that referenced this issue May 31, 2021
…ister

Remove obsolete workaround.

The regression test for rust-lang#62649 appears to pass even without the workaround.
@ocstl
Copy link

ocstl commented Jan 4, 2022

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

@jackh726
Copy link
Member

Going to close as fixed with test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-incr-comp Area: Incremental compilation C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-high High priority regression-from-stable-to-stable Performance or correctness regression from one stable version to another. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet