Allow specifying multiple bounds for same associated item (remove E0719)

[Jules-Bertholet]

This hard error serves no purpose.
Fixes #143143.

(Documentation of E0719: https://doc.rust-lang.org/stable/error_codes/E0719.html)

@rustbot label T-lang needs-fcp

[rustbot]

r? @compiler-errors

rustbot has assigned @compiler-errors.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

HIR ty lowering was modified

cc @fmease

[fmease]

more importantly cc @rust-lang/types rather than T-lang

[fmease]

^{(commenting on a random file so it's threaded)}

Thanks for incorporating my suggestion about adding more tests!

What are the interactions with trait object types? It's possible that lower_trait_object_ty still ends up rejecting such dyn-Traits (e.g., dyn Trait<X = i32, X = u64>) due to its intricate and delicate logic but I might not be right. For example, we currently reject:

#![feature(trait_alias)]
trait Iter = Iterator<Item = ()>;
fn f(_: Box<dyn Iter<Item = u64>>) {} //~ ERROR conflicting associated type bounds for `Item` when expanding trait alias

I'm curious about whether that gets triggered for sth. like dyn Trait<X = i32, X = u64> 🤔 If not, I wonder if we should then also lift this trait alias restriction?

I don't know the soundness implications of allowing these equality predicates in trait object types since I haven't spent much thought on it. In my mind, a trait object type with "impossible" existential projection predicates should be fine, it would just be impossible to construct a value of it. Anyhow, I'm not qualified enough to draw a proper conclusion.

[Jules-Bertholet]

Good catch! It looks like we do trigger that error. I added tests, and tweaked the error message to be more generic.

Interestingly, it seems that if you do:

trait Sup {
    type Assoc;
}

trait Sub: Sup<Assoc = u32> {}

type Foo = dyn Sub<Assoc = i32>;

Then no error is emitted, but Foo does not implement Sub.