Tracking issue for future-incompatbility lint order_dependent_trait_objects

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

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

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.

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.

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.

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.

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

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)

Navigation Menu

Repository navigation

Tracking issue for future-incompatbility lint `order_dependent_trait_objects` #56484

What is the warning for?

When will this warning become a hard error?

Status

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking issue for future-incompatbility lint order_dependent_trait_objects #56484

Description

What is the warning for?

When will this warning become a hard error?

Status

Activity

Centril commented on Dec 3, 2018

jonas-schievink commented on Feb 8, 2020

rlovell3 commented on Jun 19, 2023

cosmicexplorer commented on Dec 17, 2023

KisaragiEffective commented on Jan 30, 2024

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Tracking issue for future-incompatbility lint `order_dependent_trait_objects` #56484