ICE：called Option::unwrap() on a None value
#139314
Assignees
Labels
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
sososopy
added
C-bug
rustbot
added
the
needs-triage
|
I don't know the correctness of my response, but perhaps try changing the trait bound |
Zalathar
added a commit
to Zalathar/rust
that referenced
this issue
Apr 4, 2025
…li-obk Pass correct param-env to `error_implies` Duplicated comment from the test: In the error reporting code, when reporting fulfillment errors for goals A and B, we try to see if elaborating A will result in another goal that can equate with B. That would signal that B is "implied by" A, allowing us to skip reporting it, which is beneficial for cutting down on the number of diagnostics we report. In the new trait solver especially, but even in the old trait solver through things like defining opaque type usages, this `can_equate` call was not properly taking the param-env of the goals, resulting in nested obligations that had empty param-envs. If one of these nested obligations was a `ConstParamHasTy` goal, then we would ICE, since those goals are particularly strict about the param-env they're evaluated in. This is morally a fix for <rust-lang#139314>, but that repro uses details about how defining usages in the `check_opaque_well_formed` code can spring out of type equality, and will likely stop failing soon coincidentally once we start using `PostBorrowck` mode in that check. Instead, we use lazy normalization to end up generating an alias-eq goal whose nested goals woul trigger the ICE instead, since this is a lot more stable. Fixes rust-lang#139314 r? `@oli-obk` or reassign
|
@SciMind2460 ICEs shouldn't happen, even if the code is not correct. |
jieyouxu
removed
the
needs-triage
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 4, 2025
Rollup merge of rust-lang#139335 - compiler-errors:error-implies, r=oli-obk Pass correct param-env to `error_implies` Duplicated comment from the test: In the error reporting code, when reporting fulfillment errors for goals A and B, we try to see if elaborating A will result in another goal that can equate with B. That would signal that B is "implied by" A, allowing us to skip reporting it, which is beneficial for cutting down on the number of diagnostics we report. In the new trait solver especially, but even in the old trait solver through things like defining opaque type usages, this `can_equate` call was not properly taking the param-env of the goals, resulting in nested obligations that had empty param-envs. If one of these nested obligations was a `ConstParamHasTy` goal, then we would ICE, since those goals are particularly strict about the param-env they're evaluated in. This is morally a fix for <rust-lang#139314>, but that repro uses details about how defining usages in the `check_opaque_well_formed` code can spring out of type equality, and will likely stop failing soon coincidentally once we start using `PostBorrowck` mode in that check. Instead, we use lazy normalization to end up generating an alias-eq goal whose nested goals woul trigger the ICE instead, since this is a lot more stable. Fixes rust-lang#139314 r? ``@oli-obk`` or reassign
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Possible repetition with #129209
Code
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: