better errors when resolving bad Self in impl block

[compiler-errors]

1. Fix the ICE when we see things like impl Self by resolving an impl's self type outside of its own scope.
2. Fix a cycle error when we have something like impl Tr<Self::A> for Ty {} by distinguishing when we're resolving an impl's trait ref, and marking any associated types in that trait ref as ambiguous.

Fixes #93952

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[cjgillot]

I'm not really convinced by this implementation. If having Self in the type reference is illegal, we should report it right away.
Could we use a new RibKind::InImplBlockType binding Self to Res::Err, and have validate_res_from_ribs emit the error in the resolver.

[cjgillot]

Why is this required? IIUC, current_self_type is only used for diagnostics.

[compiler-errors]

it's probably not useful in that case.

[cjgillot]

I'm not sure I understand where this flag is used.

[compiler-errors]

We specifically need to deny this:

impl Trait<Self::A> for () {}

But we should not deny this:

impl Trait<Self> for () {}

So we use this flag during astconv to catch cases (like the former) where we have an associated type with a Self in the path, which without this flag would try to elaborate the supertraits of the trait ref, looking for one with the associated type.

Since resolving the trait ref would itself require resolving an associated type in the trait ref, we get a cycle error.

[compiler-errors]

Could we use a new RibKind::InImplBlockType binding Self to Res::Err, and have validate_res_from_ribs emit the error in the resolver.

@cjgillot: I could try this! Do you think that splitting out all of the combinations of Some and None in the Res::SelfTy is worthwhile?

Still not sure if this fixes the cycle error with a associated type on Self in an impl's trait ref, see the comment above for more detail. I'll do some thinking about that.

@rustbot author

[petrochenkov]

I'd personally close this and close #93952 as well as not an issue.
The error is quite clear, the erroreous case is fringe, and I don't want to add extra data to HIR only to report a different message for it.

[bors]

☔ The latest upstream changes (presumably #93938) made this pull request unmergeable. Please resolve the merge conflicts.

[compiler-errors]

Welp, don't think I'll get around to fixing this. I may re-attempt this with that rib idea suggested above later.