-Znext-solver use the trait object's own bounds instead of goal when considering builtin object bounds

[ShoyuVanilla]

Fixes #152789 and fixes #151329

r? lcnr

[lcnr]

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

rust/compiler/rustc_next_trait_solver/src/solve/assembly/mod.rs

Line 93 in 6f54d59

goal.predicate.trait_ref(cx),

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.

[ShoyuVanilla]

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

[ShoyuVanilla]

rust/compiler/rustc_next_trait_solver/src/solve/trait_goals.rs

Lines 192 to 194 in 1eb36c6

	ecx.eq(goal.param_env, goal.predicate.trait_ref, assumption_trait_pred.trait_ref)?;
	then(ecx)

We equate the goal with the assumption before entering this closure in the above lines.
However, that eq relationship does not actually hold in the problematic cases from the linked issues.

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.
Those predicates are evaluated here, in projection_may_match:

rust/compiler/rustc_next_trait_solver/src/solve/assembly/structural_traits.rs

Line 937 in 1eb36c6

ecx.try_evaluate_added_goals()

I think short-circuiting candidates for which the equality cannot hold, before entering the remaining probing, would be harmless and prevent the ICE.

In fact, adding just that early check is enough to fix the ICE in the linked issues.
But I think using trait object's own bounds instead of goal's is correct, so changed the follwing lines as well.

[ShoyuVanilla]

This change is irrelevant of the issue but seems trivial 😅

[ShoyuVanilla]

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