Split an item bounds and an item's super predicates by compiler-errors · Pull Re...

This is the moral equivalent of #107614, but instead for predicates this applies to item bounds. This PR splits out the item bounds (i.e. all predicates that are assumed to hold for the alias) from the item super predicates, which are the subset of item bounds which share the same self type as the alias.

Much like #107614, there are places in the compiler where we only care about super-predicates, and considering predicates that possibly don't have anything to do with the alias is problematic. This includes things like closure signature inference (which is at its core searching for Self: Fn(..) style bounds), but also lints like #[must_use], error reporting for aliases, computing type outlives predicates.

Even in cases where considering all of the item_bounds doesn't lead to bugs, unnecessarily considering irrelevant bounds does lead to a regression (#121121) due to doing extra work in the solver.

Example 1 - Trait Aliases

This is best explored via an example:

type TAIT<T> = impl TraitAlias<T>;

trait TraitAlias<T> = A + B where T: C;

The item bounds list for Tait<T> will include:

• Tait<T>: A
• Tait<T>: B
• T: C

While item_super_predicates query will include just the first two predicates.

Side-note: You may wonder why T: C is included in the item bounds for TAIT? This is because when we elaborate TraitAlias<T>, we will also elaborate all the predicates on the trait.

Example 2 - Associated Type Bounds

type TAIT<T> = impl Iterator<Item: A>;

The item_bounds list for TAIT<T> will include:

• Tait<T>: Iterator
• <Tait<T> as Iterator>::Item: A

But the item_super_predicates will just include the first bound, since that's the only bound that is relevant to the alias itself.

So what

This leads to some diagnostics duplication just like #107614, but none of it will be user-facing. We only see it in the UI test suite because we explicitly disable diagnostic deduplication.

Regarding naming, I went with super_predicates kind of arbitrarily; this can easily be changed, but I'd consider better names as long as we don't block this PR in perpetuity.