order_dependent_trait_objects future compatibility lint

[arielb1]

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 make order_dependent_trait_objects show up in future-breakage reports #102635

[Centril]

(pending lang team decision in #56481 or somewhere else)

[jonas-schievink]

Triage: The traitobject crate 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]

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]

Noting in light of the above comment that the breaking changes policy also linked in OP currently states:

What precisely constitutes "small" impact? This RFC does not attempt to define when the impact of a patch is "small" or "not small". We will have to develop guidelines over time based on precedent.

And it seems like this should probably be clarified so that the project can address the above comment.

[KisaragiEffective]

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.

I think it is not possible unless fix every "fix-able-dependency." It is known that fixing deep dependency will affect more crate.