Repository navigation
Trait coherency regression in 1.78 #124664
Copy link
Copy link
Closed
Labels
A-coherenceArea: CoherenceArea: CoherenceC-bugCategory: This is a bug.Category: This is a bug.T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Description
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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-coherenceArea: CoherenceArea: CoherenceC-bugCategory: This is a bug.Category: This is a bug.T-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.Performance or correctness regression from one stable version to another.
Activity
[-]Trait conflicting implementation detection regression in 1.78[/-][+]Trait coherency regression in 1.78[/+]lqd commentedon May 3, 2024
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 commentedon May 3, 2024
Yeah, this is a legitimate bug in the code sample that was shared. Downstream crates can implement
Vendorwith aProcessortype that implementsVendorProcessor<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 commentedon May 4, 2024
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>andVendorProcessor<Group>but I understand other 99% of use cases where this is broken. Closing.