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.

[lcnr]

you're right. I messed up the example.

does the following fail with the old impl? I think the issue is that we otherwise first normalize the inner, and then the outer alias 🤔

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

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

[adwinwhite]

This doesn't fail with my first commit.

It turns out when we add NormalizesTo goal for projection Assoc, we also add a nested AliasRelate goal for the inner projection This.
And we evaluate the inner projection before the outer one.
Thus when we evaluate the NormalizesTo goal of Assoc, the self_ty is already normalized.

[lcnr]

ah yeah. we never actually need to normalize the self type for normalization goals 😅 can you still add that one as a test?

[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.

[lcnr]

r=me after adding the additional test

[adwinwhite]

🤔, I don't think I have the permission to "r=you".

[lcnr]

@bors r+ rollup

[bors]

📌 Commit d2cfc47 has been approved by lcnr

It is now in the queue for this repository.