Un-shadow object bound candidate in NormalizesTo goal if self_ty is trait object

[adwinwhite]

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

r? lcnr

[lcnr]

Trait objects always have their associated types specified so candidates won't be empty.

That comments exists to state why we never treat the alias as rigid in this case?

CAn you add something along the lines of

"This is somewhat inconsistent and may make #57893 slightly easier to exploit. However, it matches the behavior of the old solver"

as a comment

View changes since this review

[lcnr]

pls add // Regression test for trait-system-refactor-initiative#whatever

[lcnr]

I think we should move this into assemble_and_evaluate_candidates as rn this doesn't handle cases where the self type is an alias, e.g. the following should still fail with ur PR

trait Trait {
    type Assoc;
}
trait Id {
    type This;
}
impl<T: ?Sized> Id for T {
    type This = T;
}

fn foo<T>(x: <dyn Trait<Assoc = T> as Trait>::Assoc) -> T
where
    <dyn Trait<Assoc = T> as Id>::This: Trait,
{
    x
}

[adwinwhite]

This doesn't fail (after fixing ?Sized bound). And the Assoc projection's self_ty is not alias?
The trait goal in param env has alias self_ty but it's irrelevant for the NormalizesTo goal.

Besides, the following doesn't fail either. Perhaps the self_ty is normalized somehow?

trait Trait {
    type Assoc;
}
trait Id {
    type This: ?Sized;
}
impl<T: ?Sized> Id for T {
    type This = T;
}

fn foo<T>(x: <<dyn Trait<Assoc = T> as Id>::This as Trait>::Assoc) -> T
where
    <dyn Trait<Assoc = T> as Id>::This: Trait,
{
    x
}

Nonetheless, I moved the code into assemble_and_evaluate_candidates and removed comments specific to NormalizesTo goal since trait goals also use this method.

[adwinwhite]

That comments exists to state why we never treat the alias as rigid in this case?

Yes, just a reminder that we won't take the inject_normalize_to_rigid_candidate code path in this case.