-
Notifications
You must be signed in to change notification settings - Fork 13k
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: Encountered unexpected type in ConstructorSet::for_ty
in rustc_pattern_analysis/src/rustc.rs
#125874
Labels
A-patterns
Relating to patterns and pattern matching
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
cushionbadak
added
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.
labels
Jun 2, 2024
rustbot
added
the
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
label
Jun 2, 2024
jieyouxu
added
A-patterns
Relating to patterns and pattern matching
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
and removed
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
labels
Jun 4, 2024
matthiaskrgr
added
the
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
label
Jun 9, 2024
searched nightlies: from nightly-2023-01-01 to nightly-2024-05-30 bisected with cargo-bisect-rustc v0.6.8Host triple: x86_64-unknown-linux-gnu cargo bisect-rustc --start=2023-01-01 --end=2024-05-30 --regress=ice --script=rustc --preserve -- 125874.rs |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 3, 2025
…d, r=<try> Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params I think this is a bit less invasive of an approach compared to rust-lang#127973. It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`. The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query. Fixes rust-lang#123141 Fixes rust-lang#125874 Fixes rust-lang#126942 Fixes rust-lang#127804 Fixes rust-lang#130967 r? oli-obk
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 3, 2025
…d, r=<try> Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`. The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query. I think this is a bit less invasive of an approach compared to rust-lang#127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did. Fixes rust-lang#123141 Fixes rust-lang#125874 Fixes rust-lang#126942 Fixes rust-lang#127804 Fixes rust-lang#130967 r? oli-obk
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Jan 3, 2025
…d, r=oli-obk Project to `TyKind::Error` when there are unconstrained non-lifetime (ty/const) impl params It splits the `enforce_impl_params_are_constrained` function into lifetime/non-lifetime, and queryfies the latter. We can then use the result of the latter query (`Result<(), ErrorGuaranteed>`) to intercept projection and constrain the projected type to `TyKind::Error`, which ensures that we leak no ty or const vars to places that don't expect them, like `normalize_erasing_regions`. The reason we split `enforce_impl_params_are_constrained` into two parts is because we only error for *lifetimes* if the lifetime ends up showing up in any of the associated types of the impl (e.g. we allow `impl<'a> Foo { type Assoc = (); }`). However, in order to compute the `type_of` query for the anonymous associated type of an RPITIT, we need to do trait solving (in `query collect_return_position_impl_trait_in_trait_tys`). That would induce cycles. Luckily, it turns out for lifetimes we don't even care about if they're unconstrained, since they're erased in all contexts that we are trying to fix ICEs. So it's sufficient to keep this check separated out of the query. I think this is a bit less invasive of an approach compared to rust-lang#127973. The major difference between this PR and that PR is that we queryify the check instead of merging it into the `explicit_predicates_of` query, and we use the result to taint just projection goals, rather than trait goals too. This doesn't require a lot of new tracking in `ItemCtxt` and `GenericPredicates`, and it also seems to not require any other changes to typeck like that PR did. Fixes rust-lang#123141 Fixes rust-lang#125874 Fixes rust-lang#126942 Fixes rust-lang#127804 Fixes rust-lang#130967 r? oli-obk
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-patterns
Relating to patterns and pattern matching
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-bug-has-test
Status: This bug is tracked inside the repo by a `known-bug` test.
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Code
(hand reduced)
dyn
added atimpl<T: ?Sized> Mirror for dyn A
, to reduce error message.original code
Meta
rustc --version --verbose
:Error output
Command:
rustc
Backtrace
Note
rustc_pattern_analysis/src/rustc.rs L412
rust/compiler/rustc_pattern_analysis/src/rustc.rs
Lines 411 to 413 in f67a1ac
The text was updated successfully, but these errors were encountered: