On conflicting assoc item bindings in trait object types, two similar errors are emitted

[fmease]

Reproducer:

fn main() {
    let _: dyn Iterator<Item = (), Item = i32>;
}

Compiler output:

error[E0719]: the value of the associated type `Item` in trait `Iterator` is already specified
 --> <anon>:1:44
  |
1 | fn main() { let _: dyn Iterator<Item = (), Item = i32>; }
  |                                 ---------  ^^^^^^^^^^ re-bound here
  |                                 |
  |                                 `Item` bound here first

error: conflicting associated type bounds for `Item`
 --> <anon>:1:20
  |
1 | fn main() { let _: dyn Iterator<Item = (), Item = i32>; }
  |                    ^^^^^^^^^^^^^---------^^----------^
  |                                 |          |
  |                                 |          `Item` is specified to be `i32` here
  |                                 `Item` is specified to be `()` here

This only happens if the provided types are "syntactically" unequal (i.e., using middle::Ty's ==, not unification). If they're equal only the 1st one is emitted.

What happens here is that the 1st diagnostic stems from our (formerly general) check we use when HIR-ty-lowering assoc item bindings and the 2nd one comes from the lowerer for trait object types, more specifically from a check that's meant to trigger in the presence of trait aliases only I'm pretty sure. I'm claiming that because the 2nd diagnostic used to say the following prior to PR #146593 / 1.92:

error: conflicting associated type bounds for `Item` when expanding trait alias
 --> <anon>:1:20
  |
1 | fn main() { let _: dyn Iterator<Item = (), Item = i32>; }
  |                    ^^^^^^^^^^^^^---------^^----------^
  |                                 |          |
  |                                 |          `Item` is specified to be `i32` here
  |                                 `Item` is specified to be `()` here

This was factually incorrect in this case obviously.

So why did PR #146593 generalize the wording (w/o addressing the "double" emission)? Well, that change originates from its closed predecessor #143146 where the (formerly general) check in lower_assoc_item_constraint was dropped entirely in favor of the one in lower_trait_object_ty, so it made sense to generalize it.

[fmease]

I'm blocking this on my PR #150843 which touches lower_trait_object_ty almost everywhere.

[fmease]

Ideally we would just drop the (formerly general) check in lower_assoc_item_constraint which is now run for trait object types since PR #146593 as that would remove a bunch of code and untangle things. Clearly, doing the check in lower_trait_object_ty after trait alias expansion is more general.

However, we can't just do that since that check permits dyn Iterator<Item = (), Item = ()> (since () == ()) which would be a behavior change and thus require an FCP.

Personally speaking I'm therefore leaning towards rejecting conflicting bindings after trait alias expansion for now even if the terms are equal (since trait aliases are unstable no FCP is needed & it can always be relaxed again in the future). Edit: This might not be as straightforward since expand_trait_aliases actually deduplicates projections, it's not just the != in lower_trait_object_ty (and I'm not sure if anyone is relying on these getting deduped).

Alternatively, I'm also fine (maybe?) with just permitting duplicate bindings in trait object types (essentially what the closed PR #143146 tried to do) assuming that's sound (again, this would need an FCP).

[fmease]

Alternatively, I'm also fine (maybe?) with just permitting duplicate bindings in trait object types (essentially what the closed PR #143146 tried to do) assuming that's sound.

Those "conflicting" bindings would simply render the trait object type impossible to construct. However we need to be wary of some weird edge cases. E.g., it's already possible to have legal "conflicting" bindings via supertrait bounds (making the dyn trait impossible to construct) but it can seemingly be observed that "closer" bindings override "farther" ones (I don't actually know why that is, I need to check later). Consider:

//@ check-pass

trait A: B<T = ()> {}
trait B {
    type T;
}

fn scope() {
    let _: <dyn A<T = i32> as B>::T = 0;
}

Here, the T = i32 actually overwrote the T = () (effectively / seemingly)!

[fmease]

Prior to PR #136458 the 2nd check (the one in lower_trait_object_ty) didn't exist and it was legal to overwrite add onto the binding that's specified in the trait alias:

// check-pass prior to PR #136458
#![feature(trait_alias)]
trait A = Tr<T = ()>;
trait Tr { type T; }
fn main() { let _: dyn A<T = i32>; }

Now, here's the kicker: Prior to #133830 or #136458 (I've yet to check), the example I've provided in #150936 (comment) didn't compile. It got rejected with (e.g., in 1.85):

error[E0284]: type annotations needed
 --> <anon>:1:89
  |
1 | #![feature(trait_alias)] trait A = Tr<T = ()>; trait Tr { type T; }  fn main() { let _: <dyn A<T = i32> as Tr>::T = 0; }
  |                                                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^ cannot infer type
  |
  = note: cannot satisfy `<dyn Tr<T = i32, T = ()> as Tr>::T == _`

Which makes sense (T = () plus T = i32 is impossible to satisfy).

This change must've been intentional, I need to reread the FCP description & comments. Edit: It is intentional (see section Implement proper precedence between supertrait and user-written projection bounds when lowering dyn types).