ICE: unexpected inference var
#123141
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.
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
matthiaskrgr
added
I-ICE
rustbot
added
the
needs-triage
|
This could be minimized further @rustbot label: E-needs-mcve |
rustbot
added
the
E-needs-mcve
jieyouxu
removed
the
needs-triage
|
Minimized a bit more struct Foo<const N: usize>;
trait Bar {
type Item;
fn c() -> Self::Item;
}
impl<const N: usize> Bar for Foo<{ rem }> {
type Item = Foo<N>;
}
fn main() {
let _: Foo<0> = <Foo<0> as Bar>::c();
} |
jieyouxu
added
S-has-mcve
matthiaskrgr
added
the
S-bug-has-test
|
the same cause as #122638 |
|
Here is a reproduction using type parameters instead of const parameters and with a minimal amount of unrelated errors and no feature gates: trait Trait {
fn next(self) -> Self::Item;
type Item;
}
struct Foo<T: ?Sized>(T);
impl<T: ?Sized, U> Trait for Foo<U> {
type Item = Foo<T>;
fn next(self) -> Self::Item {
loop {}
}
}
fn opaque() -> impl Trait {
Foo::<_>(10_u32)
}
fn main() {
opaque().next();
}In order for this to reproduce the unconstrained generic parameter must not have any bounds involving it that would not succeed if it were an inference variable. For example without the The root cause here is that we attempt to normalize using the Program output
|
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
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustcProgram output
The text was updated successfully, but these errors were encountered: