Skip to content

Broken MIR: relate_type_and_user_type may receive unnormalized types #141708

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

Closed
compiler-errors opened this issue May 28, 2025 · 0 comments · Fixed by #141703
Closed

Broken MIR: relate_type_and_user_type may receive unnormalized types #141708

compiler-errors opened this issue May 28, 2025 · 0 comments · Fixed by #141703
Assignees
Labels
fixed-by-next-solver Fixed by the next-generation trait solver, `-Znext-solver`. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-types Relevant to the types team, which will review and decide on the PR/issue.

Comments

@compiler-errors
Copy link
Member

This code ICEs:

trait Foo<'a> {
    type Assoc;
}

impl<T> Foo<'_> for T {
    type Assoc = T;
}

fn foo<'b: 'b, T: for<'a> Foo<'a>, F: for<'a> Fn(<T as Foo<'a>>::Assoc)>(_: F) -> (T, F) {
    todo!()
}

fn main() {
    let (x, c): (i32, _) = foo::<'static, _, _>(|_| {});
}

We create a very sneaky closure type that has the signature of for<'a> fn(<i32 as Foo<'a>>::Assoc). Note that this type is not normalized, because of higher-ranked normalization problems w/ the old trait solver.

We then store this type into c in the let statement, and because it's a pattern, we end up storing a user type annotation that links it to the field ascription. Since it's a pattern with a single field place elem, we end up normalizing the closure type here:

self.structurally_resolve(ty, locations)

note that this is a full normalization in the old solver.

We then try to relate the unnormalized and normalized closure signatures, which fails in the old solver.

@compiler-errors compiler-errors added the C-bug Category: This is a bug. label May 28, 2025
@rustbot rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label May 28, 2025
@compiler-errors compiler-errors self-assigned this May 28, 2025
@compiler-errors compiler-errors added I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ and removed C-bug Category: This is a bug. needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels May 28, 2025
@compiler-errors compiler-errors added T-types Relevant to the types team, which will review and decide on the PR/issue. fixed-by-next-solver Fixed by the next-generation trait solver, `-Znext-solver`. labels May 28, 2025
@bors bors closed this as completed in bace7f9 May 30, 2025
rust-timer added a commit that referenced this issue May 30, 2025
Rollup merge of #141703 - compiler-errors:deref-place, r=lcnr

Structurally normalize types as needed in `projection_ty_core`

Introduce a `structurally_normalize` callback to `projection_ty_core`, and then use it before we match on the ty kind in `projection_ty_core`.

Previously we were only structurally normalizing the return type of the `handle_field` struct, but if we were to (e.g.) apply a deref projection to that type, then the resulting type is not guaranteed to be structurally normalized and any subsequent projections applied would ICE.

Fixes rust-lang/trait-system-refactor-initiative#221

I'll leave a few comments inline to explain the changes.

r? lcnr

---

Also fixes #141708
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
fixed-by-next-solver Fixed by the next-generation trait solver, `-Znext-solver`. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ T-types Relevant to the types team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants