Distinguish versions of a crate loaded from the sysroot and from cargo

[jyn514]

Code

// inner/Cargo.toml
[package]
name = "inner"
edition = "2021"

[dependencies]
hashbrown = "0.12.3"

// inner/src/lib.rs
pub fn foo(_: hashbrown::HashMap<u32, u32>) {}

// outer/src/main.rs
#![feature(rustc_private)]
extern crate hashbrown;

fn main() {
    let map = hashbrown::HashMap::default();
    inner::foo(map);
}

Current output

error[E0308]: mismatched types
   --> src/main.rs:6:16
    |
6   |     inner::foo(map);
    |     ---------- ^^^ expected `HashMap<u32, u32>`, found `HashMap<_, _, _, _>`
    |     |
    |     arguments to this function are incorrect
    |
    = note: `HashMap<_, _, _, _>` and `HashMap<u32, u32>` have similar names, but are actually distinct types
note: `HashMap<_, _, _, _>` is defined in crate `hashbrown`
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
note: `HashMap<u32, u32>` is defined in crate `hashbrown`
   --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
    |
188 | pub struct HashMap<K, V, S = DefaultHashBuilder, A: Allocator + Clone = Global> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `hashbrown` are being used?
note: function defined here
   --> /Users/jyn/src/example/inner/src/lib.rs:1:8
    |
1   | pub fn foo(_: hashbrown::HashMap<u32, u32>) {}
    |        ^^^

Desired output

note: `HashMap<_, _, _, _>` is defined in crate `hashbrown`
   --> /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
   = note: loaded from /Users/jyn/.local/lib/rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/lib/libhashbrown-016a8bf1dc67c69f.rlib
   = note: which is in the compiler's "sysroot": https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html#what-is-a-sysroot
note: `HashMap<u32, u32>` is defined in crate `hashbrown` (loaded from `/Users/jyn/.local/lib/cargo/target/debug/deps/`)
   --> /Users/jyn/.local/lib/cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1
    |
188 | pub struct HashMap<K, V, S = DefaultHashBuilder, A: Allocator + Clone = Global> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: loaded from /Users/jyn/.local/lib/cargo/target/debug/deps/libhashbrown-408ce4dce55d643d.rmeta
    = note: perhaps two different versions of crate `hashbrown` are being used?

Rationale and extra context

It's not clear that "/Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/hashbrown-0.12.3/src/map.rs:188:1" is referring to a crate loaded from the sysroot; that path doesn't correspond to anything on disk. It would be nice to explain what's going on; when dealing with sysroots the exact paths of the artifacts often really are important.

Other cases

No response

Anything else?

This is minimized from a real error @aDotInTheVoid saw in rustdoc:

   Compiling rustdoc v0.0.0 (/home/alona/dev/rust/rust/src/librustdoc)
error[E0308]: mismatched types
   --> src/librustdoc/json/mod.rs:235:13
    |
235 |             index,
    |             ^^^^^ expected `rustc_hash::FxHasher`, found `FxHasher`
    |
    = note: `FxHasher` and `rustc_hash::FxHasher` have similar names, but are actually distinct types
note: `FxHasher` is defined in crate `rustc_hash`
   --> /cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1
note: `rustc_hash::FxHasher` is defined in crate `rustc_hash`
   --> /home/alona/.cargo/registry/src/index.crates.io-6f17d22bba15001f/rustc-hash-1.1.0/src/lib.rs:60:1
    |
60  | pub struct FxHasher {
    | ^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `rustc_hash` are being used?

[estebank]

Current output:

error[E0308]: mismatched types
   --> src/main.rs:6:16
    |
6   |     inner::foo(map);
    |     ---------- ^^^ expected `HashMap<u32, u32>`, found `HashMap<_, _, _, _>`
    |     |
    |     arguments to this function are incorrect
    |
note: two different versions of crate `hashbrown` are being used; two types coming from two different versions of the same crate are different types even if they look the same
    |
   ::: /home/gh-estebank/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/hashbrown-0.12.3/src/map.rs:188:1
    |
188 | pub struct HashMap<K, V, S = DefaultHashBuilder, A: Allocator + Clone = Global> {
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this is the expected type `hashbrown::map::HashMap`
   --> /rust/deps/hashbrown-0.15.2/src/map.rs:185:1
    |
    = note: this is the found type `hashbrown::HashMap`
    |
   ::: src/main.rs:2:1
    |
2   | extern crate hashbrown;
    | ----------------------- one version of crate `hashbrown` used here, as a direct dependency of the current crate
...
6   |     inner::foo(map);
    |     ----- one version of crate `hashbrown` used here, as a dependency of crate `inner`
    = help: you can use `cargo tree` to explore your dependency tree
note: function defined here
   --> /home/gh-estebank/sysrootdep/inner/src/lib.rs:1:8
    |
1   | pub fn foo(_: hashbrown::HashMap<u32, u32>) {}
    |        ^^^

Do you feel this is enough specificity @jyn514?

[jyn514]

The language there seems mostly the same. The only thing that’s improved is that it now says /rust/deps instead of pointing to the cargo registry. And that’s easy to overlook, and I’m not entirely sure it’s not just because you don’t have the rustc-src component installed. So I would prefer to keep this open until the message explicitly mentions the sysroot.

(I do think the message is more clear if you do in fact actually have two different versions of hashbrown, like would normally be the case when this error happens. but that is not the case in the original issue, notice how the version numbers are the same.)

[jyn514]

in particular, the new language about cargo tree is very helpful when you’re using cargo, and actively misleading if you’re loading dependencies from sysroot.

[estebank]

For my locally built rustc, I get the right span. It's for my nightly that it doesn't display it (I think because of the path renaming/anonymization). I'm not quite sure how to get the right sysroot path (corresponding to /rust/deps/ on nightly) so that we could identify this is happening and provide some extra text in the output to make that clearer.

[jyn514]

i would expect that rustc_metadata stores info somewhere about whether the crate was loaded from a -L deps/ folder or from the sysroot? i strongly think we should not do this based on the original source span, we should do it based on the location of the .rmeta that got loaded.

[estebank]

I'm just not sure that we still have all of the necessary information by hir typeck.

[bjorn3]

rustc_metadata stores the path to the rlib/dylib/rmeta file(s) for the crate. And it should be easy to add another flag stating if the crate came from the sysroot or not.