We don't fully validate relaxed trait bounds on the RHS of trait aliases (should we actually reject them outright?)

[fmease]

CC #135841 (review), #142693

This currently passes compilation while it shouldn't:

#![feature(trait_alias)]

trait A = ?Sized + ?Sized; // should be rejected due to duplicate relaxed trait bounds
trait B = ?Iterator; // should be rejected since `Iterator` is not a default trait

// (also doesn't error if referenced — in case anyone was wondering)
//fn f<T: A + B>() {}

[fmease]

Actually, I wonder if we should deny relaxed bounds in this position outright. More and more I'm leaning towards that. Reasoning: We don't perform "sized elaboration" for this position.

If you'd like to define trivial trait alias, you cam simply do trait Trivial =;, no ?Sized needed.

[fmease]

Reasoning: We don't perform "sized elaboration" for this position.

For example, this compiles just fine:

#![feature(trait_alias)]

trait Trivial =;

fn check<T: ?Sized + Trivial>() {}

fn main() {
    check::<[u8]>(); // OK
}

meaning Trivial does not require Sized, so there's nothing to relax at the def site and trait Trivial = ?Sized; should just be written trait Trivial =;.