hmm, thinking about this, given

pub trait Trait<T> {
    type Assoc;
}

pub trait Foo {
    type FooAssoc;
}

pub struct Wrap<U: Foo>(<dyn Trait<i32, Assoc = i64> as Trait<U::FooAssoc>>::Assoc)
where
    dyn Trait<i32, Assoc = i64>: Trait<U::FooAssoc>;

we're checking dyn Trait<i32, Assoc = i64>: Trait<U::FooAssoc> and try to do this via the builtin impl.

This builtin impl should be

impl Trait<i32> for dyn Trait<i32, Assoc = i64>
where
    i32: Sized,
    // we eagerly replace `<Self as Trait<i32>>::Assoc` with `i64` when
    // emitting the impl to avoid non-productive cycles.
    <Self as Trait<i32>>::Assoc: Sized,
{
    type Assoc = i64;
}

The builtin impl only applies here if U::FooAssoc is equal to i32. Generating the builtin impl should not actually care about the trait goal we're proving.

I think the bug is here

We should compute the where-clauses of the builtin impl using only the object type, not the goal we actually have to prove.

This builtin impl won't be applicable for U::FooAssoc because fn probe_and_match_goal_against_assumption will already reject the builtin candidate due to a type mismatch in the trait arguments.

That looks correct. I was being too narrow in my reasoning about the cause 😅

Hmm, the CI failure looks sus. Am I doing somewhat very incorrect thingy?

Because this additional goal is introduced through that equality, the ICE still occurs even if we use the trait ref from the trait object (instead of the goal's trait ref) when calling predicates_for_object_candidate.

How? do you still have the code which ICEd when using the trait object arguments lying around?

How? do you still have the code which ICEd when using the trait object arguments lying around?

The very same code from the beginning

pub trait Trait<T> {
    type Assoc;
}

pub trait Foo {
    type FooAssoc;
}

pub struct Wrap<U: Foo>(<dyn Trait<i32, Assoc = i64> as Trait<U::FooAssoc>>::Assoc)
where
    dyn Trait<i32, Assoc = i64>: Trait<U::FooAssoc>;

fn main() {}

but maybe I've done what you said in a very wrong way, as the CI failed with very suspicious segfault: https://github.com/rust-lang/rust/actions/runs/22516543500/job/65235925254

but why:tm:

if you use the trait object itself to build the where-clauses, when do you encounter Trait<U::FooAssoc> while replacing stuff?

It is encountered before replacing things.

The replacement happens in L90, but we equate the goal with the assumption in L85 with probe_and_match_goal_against_assumption, before calling the closure. So, the nested goal added by such equating includes Trait<U::FooAssoc>.

We are currently(without this PR) adding such goals in L936, but even though we fix it by using trait object itself instead of goal, we are still adding it before replacing, so still errors on L937

but that's fine, is it not? the builtin impl should not apply here 🤔

we want to use the where-clause after all

Yeah, such unprovable nested goal itself is fine and correct.

So, my intention of that line was to short circuit such unappliable builtin impl before trying replacements

ah, that's yeah... whether the projection matches shouldn't depend on goals from the parent. Eagerly checking whether the nested goals of equating the signature succeeds does fix this issue, but in theory, the try_evaluate_added_goals call there can make progress but not error, and if you call it we then get an error, so the ICE is still theoretically reachable 🤔

Given the way this is setup, all projections should structurally match and we shouldn't have to do any interesting type system stuff there at all. Could you replace the code to check whether the arguments are structurally equal instead of doing proper type system equality?

Given the way this is setup, all projections should structurally match and we shouldn't have to do any interesting type system stuff there at all. Could you replace the code to check whether the arguments are structurally equal instead of doing proper type system equality?

Oh, that sounds like a correct way. Would it be sth like the following?

    fn projection_may_match(
        &mut self,
        source_projection: ty::Binder<I, ty::ProjectionPredicate<I>>,
        target_projection: ty::AliasTerm<I>,
    ) -> bool {
        source_projection.item_def_id() == target_projection.def_id
            && self
                .ecx
                .probe(|_| ProbeKind::ProjectionCompatibility)
                .enter(|ecx| -> Result<_, NoSolution> {
                    let source_projection = ecx.instantiate_binder_with_infer(source_projection);
-                   ecx.eq(self.param_env, source_projection.projection_term, target_projection)?;
-                   ecx.try_evaluate_added_goals()
+                   ecx.eq_structurally_relating_aliases(self.param_env, source_projection.projection_term, target_projection)
                })
                .is_ok()
    }

should be source_projection.no_bound_vars().unwrap() == target_projection (likely with a resolve_vars_if_possible call before then)

Uh-oh, I encountered the very same problem expressed in this test:
https://github.com/rust-lang/rust/pull/139774/changes#diff-30c364a67db542a51da9d3cc9120515d449317be5a564efe64fe6ec01e9913d4
The test ICEs with exactly the same reason the test says and looks like structural equality isn't enough 🤔.

Would it make sense to do try_evaluate_added_goals above in a probe? It may still do not error out the when it should but it won't progress the context at least. It may error afterwards in projection_may_match together with the added eq relation between projections and then ICE again, but it would fix some cases, such as regression tests in this PR.

Or maybe I should devise more radical, correct fix. Maybe replacing projections before matching the goal against the assumption, or calling projection_match with a fresh new obligation ctxt?