ICE: Failed to extract DefId: local_def_id_to_hir_id #99233
Assignees
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) ❄️
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-incr-comp
Working group: Incremental compilation
Comments
afonso360
added
C-bug
|
Note:
|
|
This seems to have appeared in
The last 2 feel more likely to me because the repro involves a failing build. This is of course an incremental compilation ICE, so cc @rust-lang/wg-incr-comp. |
lqd
added
regression-from-stable-to-nightly
rustbot
added
the
I-prioritize
|
I've checked locally that:
To check if the unexpected combination of the commits in this rollup causes this issue, I've also built the #98794 branch itself, so the result is independent of the previous 3 PRs (but depends on other PRs in the nightly): it does ICE as well. All this makes me think that #98794 is the likely source of the regression in this rollup, cc PR author @compiler-errors and PR reviewer @michaelwoerister. I don't know what is the priority/severity of this issue, and we don't have an MCVE to add as test yet (I'll try to see how hard that is, wasmtime and cranelift are huge), but I could post a revert if @rust-lang/wg-incr-comp wants one. |
|
That makes sense. It was probably foolish to store a span in the first place anyways in a cacheable key like SelectionError. I'll look into fixing it, or else revert. @rustbot claim |
|
Okay, so this is a deeper issue than just my PR. I reverted my PR and added the line in the same place that I was touching in So my PR is only the "cause" insofar as it adds a new call to the |
inquisitivecrystal
removed
the
I-prioritize
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this issue
Dec 13, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
Dylan-DPC
added a commit
to Dylan-DPC/rust
that referenced
this issue
Dec 13, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by ``@lcnr)`` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 14, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 14, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by ``@lcnr)`` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 15, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by ```@lcnr)``` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this issue
Dec 15, 2022
…env-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by ````@lcnr)```` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Dec 15, 2022
…v-2, r=estebank Highlight conflicting param-env candidates, again Un-reverts rust-lang#98794 (i.e. reverts rust-lang#99290). The previous time I attempted to land this PR, it was because of an incremental issue (rust-lang#99233). The repro instructions in the issue is no longer manifest the ICE -- I think it's because this ambiguity code was refactored (I think by `@lcnr)` to no longer store the ambiguities in the fulfillment error, but instead recompute them on the fly. The main motivation for trying to re-land this is that it fixes rust-lang#105131 by highlighting the root-cause of the issue, which is conflicting param-env candidates: ``` error[E0283]: type annotations needed: cannot satisfy `Self: Gen<'source>` | note: multiple `impl`s or `where` clauses satisfying `Self: Gen<'source>` found --> $DIR/conflicting-bounds.rs:3:1 | LL | pub trait Gen<'source> { | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | Self: for<'s> Gen<'s, Output = T>; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0283`. ``` Fixes rust-lang#105131. Fixes (again) rust-lang#98786
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey, I hit this ICE while working on cranelift and I don't really know how to minimize it. Its a huge project.
This seems to be related (possibly a dup) of #97143.
Code
Since it may be incremental compilation (see #97143) related I have two branches, one before the ICE and one that triggers the ICE.
Here's the example code before the crash
https://github.com/afonso360/wasmtime/tree/rustc-ice-repro-before
and after
https://github.com/afonso360/wasmtime/tree/rustc-ice-repro-after
To reproduce do the following:
rustc-ice-repro-beforegit submodule update --initcd craneliftcargo build(this fails to compile, but that's okay)git checkout rustc-ice-repro-aftercargo buildThis seems to trigger the ICE even after
cargo clean. Doing acargo cleanand then compilingrustc-ice-repro-afterfixes the issue. However going fromrustc-ice-repro-beforetorustc-ice-repro-afterreliably triggers the ICE for me.Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: