Trait coherency regression in 1.78

[w4]

Code

I tried this code:

trait Vendor {
    type Processor<'a>: VendorProcessor;
}

trait VendorProcessor {
    type EventGroup: Group;
}

trait Group {}

trait EventProcessor<T> {}

struct MyEventProcessor<T: Vendor> {
    t: T,
}

struct MyEvent {}

impl Group for MyEvent {}

impl<T: Vendor> EventProcessor<MyEvent> for MyEventProcessor<T> {}

impl<T, Group> EventProcessor<Group> for MyEventProcessor<T>
where
    T: Vendor,
    for<'a> T::Processor<'a>: VendorProcessor<EventGroup = Group>,
{}

I expected a working build.

Instead, this happened:

error[E0119]: conflicting implementations of trait `EventProcessor<MyEvent>` for type `MyEventProcessor<_>`
  --> minimal-repro/src/lib.rs:23:1
   |
21 |   impl<T: Vendor> EventProcessor<MyEvent> for MyEventProcessor<T> {}
   |   --------------------------------------------------------------- first implementation here
22 |
23 | / impl<T, Group> EventProcessor<Group> for MyEventProcessor<T>
24 | | where
25 | |     T: Vendor,
26 | |     for<'a> T::Processor<'a>: VendorProcessor<EventGroup = Group>,
   | |__________________________________________________________________^ conflicting implementation for `MyEventProcessor<_>`

If this was a bugfix for trait coherency, it doesn't seem to have been documented in the changelog. The two implementations could technically be irrefutably non-conflicting though if there is no impl VendorProcessor<EventGroup = MyEvent> on private types.

Version it worked on

It most recently worked on: 1.77.2

Version with regression

rustc --version --verbose:

rustc 1.78.0 (9b00956e5 2024-04-29)
binary: rustc
commit-hash: 9b00956e56009bab2aa15d7bff10916599e3d6d6
commit-date: 2024-04-29
host: aarch64-apple-darwin
release: 1.78.0
LLVM version: 18.1.2

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged

[lqd]

This is from #120584, I think it was expected because of existing brokenness but I may be wrong and see no FCP, so will cc its author @compiler-errors.

[compiler-errors]

Yeah, this is a legitimate bug in the code sample that was shared. Downstream crates can implement Vendor with a Processor type that implements VendorProcessor<EventGroup = MyEvent>. Coherence doesn't take into account the privacy of the items, so privacy here doesn't really matter.

For the record, this also would have begun to fail when we land the new trait solver for coherence (#121848) which will ideally happen soon.

[w4]

Thanks guys. It is clear now that this code sample only compiled because of the HRTB, but it was nice because the trait solver did actually work correctly here for our particular use case, as it was able to disambiguate between our usages of VendorProcessor<MyEvent> and VendorProcessor<Group> but I understand other 99% of use cases where this is broken. Closing.