Change:
//@ only-linux //@ ignore-wasm32 //@ ignore-wasm64 <ins> // ignore-tidy-linelength </ins> use run_make_support::{rust_lib_name, rustc}; fn main() { rustc().input("multiple-dep-versions-1.rs").run(); rustc().input("multiple-dep-versions-2.rs").extra_filename("2").metadata("2").run(); <ins> rustc() .input("multiple-dep-versions-3.rs") .extern_("dependency", rust_lib_name("dependency2")) .run(); </ins> rustc() .input("multiple-dep-versions.rs") .extern_("dependency", rust_lib_name("dependency")) <del> .extern_("dep_2_reexport", rust_lib_name("dependency2")) </del> <ins> .extern_("dep_2_reexport", rust_lib_name("foo")) </ins> .run_fail() .assert_stderr_contains( <del> "you have multiple different versions of crate `dependency` in your dependency graph", </del> <ins> r#"error[E0277]: the trait bound `dep_2_reexport::Type: Trait` is not satisfied --> multiple-dep-versions.rs:7:18 | 7  |     do_something(Type); |     ------------ ^^^^ the trait `Trait` is not implemented for `dep_2_reexport::Type` |     | |     required by a bound introduced by this call | help: there are multiple different versions of crate `dependency` the your dependency graph --> multiple-dep-versions.rs:1:1 | 1  | extern crate dep_2_reexport; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ one version of crate `dependency` is used here, as a dependency of crate `foo` 2  | extern crate dependency; | ^^^^^^^^^^^^^^^^^^^^^^^^ one version of crate `dependency` is used here, as a direct dependency of the current crate"#, ) .assert_stderr_contains( r#" 3  | pub struct Type(pub i32); | ^^^^^^^^^^^^^^^ this type implements the required trait 4  | pub trait Trait { | --------------- this is the required trait"#, ) .assert_stderr_contains( r#" 3  | pub struct Type; | ^^^^^^^^^^^^^^^ this type doesn't implement the required trait"#, ) .assert_stderr_contains( r#" error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope --> multiple-dep-versions.rs:8:10 | 8 |     Type.foo(); |          ^^^ method not found in `Type` | note: there are multiple different versions of crate `dependency` in the dependency graph"#, ) .assert_stderr_contains( r#" 4 | pub trait Trait { | ^^^^^^^^^^^^^^^ this is the trait that is needed 5 |     fn foo(&self); |     -------------- the method is available for `dep_2_reexport::Type` here | ::: multiple-dep-versions.rs:4:32 | 4 | use dependency::{do_something, Trait}; |                                ----- `Trait` imported here doesn't correspond to the right version of crate `dependency`"#, </ins> ) .assert_stderr_contains( <del> "two types coming from two different versions of the same crate are different types  even if they look the same", </del> <ins> r#" 4 | pub trait Trait { | --------------- this is the trait that was imported"#, </ins> ) <del> .assert_stderr_contains("this type doesn't implement the required trait") .assert_stderr_contains("this type implements the required trait") .assert_stderr_contains("this is the required trait"); </del> <ins> .assert_stderr_contains( r#" error[E0599]: no function or associated item named `bar` found for struct `dep_2_reexport::Type` in the current scope --> multiple-dep-versions.rs:9:11 | 9 |     Type::bar(); |           ^^^ function or associated item not found in `Type` | note: there are multiple different versions of crate `dependency` in the dependency graph"#, ) .assert_stderr_contains( r#" 4 | pub trait Trait { | ^^^^^^^^^^^^^^^ this is the trait that is needed 5 |     fn foo(&self); 6 |     fn bar(); |     --------- the associated function is available for `dep_2_reexport::Type` here | ::: multiple-dep-versions.rs:4:32 | 4 | use dependency::{do_something, Trait}; |                                ----- `Trait` imported here doesn't correspond to the right version of crate `dependency`"#, ); </ins> }

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.