"the compiler unexpectedly panicked" in try_normalize_generic_arg_after_erasing_regions
#130967
Labels
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.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
findepi
added
C-bug
rustbot
added
the
needs-triage
|
Reduced: trait Producer {
type Produced;
fn make_one() -> Self::Produced;
}
impl<E: ?Sized> Producer for () {
type Produced = Option<E>;
fn make_one() -> Self::Produced {
loop {}
}
} |
matthiaskrgr
added
the
S-bug-has-test
Noratrieb
removed
the
needs-triage
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
Code
Meta
rustc --version --verbose:nightly panics as well
Error output
Backtrace
The text was updated successfully, but these errors were encountered: