Change:
} } <ins> fn detect_and_explain_multiple_crate_versions( &self, err: &mut Diag<'_>, item_def_id: DefId, hir_id: hir::HirId, rcvr_ty: Ty<'_>, ) -> bool { let hir_id = self.tcx.parent_hir_id(hir_id); let Some(traits) = self.tcx.in_scope_traits(hir_id) else { return false }; if traits.is_empty() { return false; } let trait_def_id = self.tcx.parent(item_def_id); let krate = self.tcx.crate_name(trait_def_id.krate); let name = self.tcx.item_name(trait_def_id); let candidates: Vec<_> = traits .iter() .filter(|c| { c.def_id.krate != trait_def_id.krate && self.tcx.crate_name(c.def_id.krate) == krate && self.tcx.item_name(c.def_id) == name }) .map(|c| (c.def_id, c.import_ids.get(0).cloned())) .collect(); if candidates.is_empty() { return false; } let item_span = self.tcx.def_span(item_def_id); let msg = format!( "there are multiple different versions of crate `{krate}` in the dependency graph", ); let trait_span = self.tcx.def_span(trait_def_id); let mut multi_span: MultiSpan = trait_span.into(); multi_span.push_span_label(trait_span, format!("this is the trait that is needed")); let descr = self.tcx.associated_item(item_def_id).descr(); multi_span .push_span_label(item_span, format!("the {descr} is available for `{rcvr_ty}` here")); for (def_id, import_def_id) in candidates { if let Some(import_def_id) = import_def_id { multi_span.push_span_label( self.tcx.def_span(import_def_id), format!( "`{name}` imported here doesn't correspond to the right version of crate  `{krate}`", ), ); } multi_span.push_span_label( self.tcx.def_span(def_id), format!("this is the trait that was imported"), ); } err.span_note(multi_span, msg); true } </ins> /// issue #102320, for `unwrap_or` with closure as argument, suggest `unwrap_or_else` /// FIXME: currently not working for suggesting `map_or_else`, see #102408 pub(crate) fn suggest_else_fn_with_closure(

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.