Repository navigation
Tracking issue for future-incompatbility lint order_dependent_trait_objects #56484
Description
This is the summary issue for the order_dependent_trait_impls
future-compatibility warning and other related errors. The goal of
this page is describe why this change was made and how you can fix
code that is affected by it. It also provides a place to ask questions
or register a complaint if you feel the change should not be made. For
more information on the policy around future-compatibility warnings,
see our breaking change policy guidelines.
What is the warning for?
As in issue #33140, rustc sometimes treats "seemingly-identical" trait object types as different. For example, Send + Sync and Sync + Send are treated as different types.
This occurs because the first trait in a trait object is treated specially in the compiler, which means that Send + Sync has its "first trait" being Send and Sync + Send has its "first trait" being Sync. That is a bug that we want to fix.
However, because the compiler made this distinction, it was possible to implement a trait separately for each of these types, for example:
trait Foo {
fn xyz();
}
impl Foo for dyn Send + Sync {
fn xyz() {
println!("Hi I'm Send + Sync");
}
}
impl Foo for dyn Sync + Send {
//~^ ERROR conflicting implementations
fn xyz() {
println!("Hi I'm Sync + Send");
}
}
fn main() {
<dyn Send + Sync>::xyz();
<dyn Sync + Send>::xyz();
}This obviously can't work if Send + Sync & Sync + Send are the same type! Therefore, it is being made into a coherence error.
To fix the warnings, remove all but one of the impls - e.g. the Sync + Send impl.
When will this warning become a hard error?
At the beginning of each 6-week release cycle, the Rust compiler team
will review the set of outstanding future compatibility warnings and
nominate some of them for Final Comment Period. Toward the end of
the cycle, we will review any comments and make a final determination
whether to convert the warning into a hard error or remove it
entirely.
Status
- introduced by add coherence future-compat warnings for marker-only trait objects #56481
- changed to
deny-by default and report in deps in makeorder_dependent_trait_objectsshow up in future-breakage reports #102635
Activity
Centril commentedon Dec 3, 2018
(pending lang team decision in #56481 or somewhere else)
jonas-schievink commentedon Feb 8, 2020
Triage: The
traitobjectcrate has still not been fixed (fix still pending in reem/rust-traitobject#6), but this has been a warning for over a year at this point.rlovell3 commentedon Jun 19, 2023
There is a ton of code that, down in its bowels, uses traitobject v0.1.0, and that crate is going to cause a lot of Rust-dependent projects to fail when this warning becomes a compile break. The maintainer seems to not be maintaining it any further. Is there someone on the Rust team that could take a look at it, and possibly fork it/fix it? Or any one of you Rust super-users? It is impossible to justify pushing something to production when we get a warning that something soon will break. As an example, ALL of the various derivatives of the Rust Book contain examples using Iron. But Iron depends on traitobject. I just spent a day working on a simple https server with iron, but due to the warning, I'm trashing the project and starting over with actix-web.
cosmicexplorer commentedon Dec 17, 2023
Noting in light of the above comment that the breaking changes policy also linked in OP currently states:
And it seems like this should probably be clarified so that the project can address the above comment.
KisaragiEffective commentedon Jan 30, 2024
I think it is not possible unless fix every "fix-able-dependency." It is known that fixing deep dependency will affect more crate.
[-]`order_dependent_trait_impls` future compatibility lint[/-][+]`order_dependent_trait_objects` future compatibility lint[/+][-]`order_dependent_trait_objects` future compatibility lint[/-][+]Tracking issue for future-incompatbility lint `order_dependent_trait_objects`[/+]Auto merge of rust-lang#136968 - oli-obk:bye-bye, r=<try>
Rollup merge of rust-lang#136968 - oli-obk:bye-bye, r=compiler-errors
Rollup merge of rust-lang#136968 - oli-obk:bye-bye, r=compiler-errors
Unrolled build for rust-lang#136968
fix(vendor): update websocat to v1.14.1 for Rust 1.87+ compat
fix(feed): pin nightly toolchain to unbreak docker build (#528)