Improve unconstrained impl diagnostic (fixes #107295)

[LlewVallis]

Fixes #107295

Problem

When a type/lifetime/const generic param is unconstrained (as defined by the rules in this RFC) the current diagnostic isn't very helpful - it just tells you the param wasn't constrained. It isn't obvious (without having read the RFC) what can be done to make the param constrained.

Solution

We add some additional notes to the existing diagnostic:

• In all cases, this PR adds an extra note which tells the user under what circumstances a generic is constrained. This message is slightly different depending on whether this is an impl trait or an inherent impl. The message slightly oversimplifies things to be more understandable, but the edge cases it misses are covered by the special messages below:
  • If the LHS was the thing being implemented (i.e. circular), then we use an extra message to explain that circularity isn't allowed
  • Otherwise, if the unconstrained param was mentioned in the RHS of an equality w/ a projection/associated-type then we add a message saying that this must mean the LHS of the equality has an unconstrained param

I added a few UI tests which probably explain these messages better than I have here :)

After looking at the RFC I linked, AFAICT there are no more edge cases where the dot points above could be incorrect, but I'm not an expert, so please correct me if there are.

---

Also as a side note - the enforce_impl_params_are_constrained function is getting a bit long, lmk if you want me to split it up.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @wesleywiser (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[compiler-errors]

r? types

[fmease]

I haven't read the rest of your impl, this is just drive-by commentary.

Could please turn these bools into custom enums? And merge these three flags as much as possible unless they are already mutually exclusive?

[LlewVallis]

Yep 👍 is_impl_trait is orthogonal to the other two booleans, but is_bound_to_projection and is_bound_to_circular_projection can be merged

[LlewVallis]

Almost forgot, but wanted to add a quick note/question regarding skip_binder here... from what I understand, binders correspond to things like for<'a>, and skip_binder is generally a bad idea since it just unwraps the binder wo/ updating references to the quantifier.

My Q: is this specific usage safe? Or is some else more appropriate? (My understanding of this is a bit hazy 🙂)

[bors]

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

[Dylan-DPC]

@LlewVallis if you can resolve the conflicts, we can push this forward for a review. Thanks

[LlewVallis]

Hey 👋 I'm short on time lately, so might leave this for someone else to pick up