Cargo clain git dependencies are different, when different, but still uniquely identifiable substring is used

[xNxExOx]

I tried this code (2 different Cargo.toml that are part of same build tree):

sr_libs = { rev = "91a97919", git = "https://gitlab.com/skylords-reborn/rust-libraries", features=["serde"] }

sr_libs = { rev = "91a9791", git = "https://gitlab.com/skylords-reborn/rust-libraries", features=["serde"] }

I expected to see this happen: Build OK, because both refer to same version, and both use same local folder C:\Users\xxxku\.cargo\git\checkouts\rust-libraries-d71f37936ba3494c\91a9791\

Instead, this happened: mismatched types between these two same versions

error[E0308]: mismatched types
   --> src\networking\connect.rs:646:86
    |
646 |                     crate::patches::changes::chat_commands::ai::match_command(*step, &*command);
    |                     ---------------------------------------------------------        ^^^^^^^^^ expected `RequestCommand`, found a different `RequestCommand`
    |                     |
    |                     arguments to this function are incorrect
    |
    = note: `RequestCommand` and `RequestCommand` have similar names, but are actually distinct types
note: `RequestCommand` is defined in crate `utils`
   --> C:\Users\xxxku\.cargo\git\checkouts\rust-libraries-d71f37936ba3494c\91a9791\utils\src\commands\command_impl.rs:212:1
    |
212 | #[macro_rules_attribute(message_request_command !)]
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: `RequestCommand` is defined in crate `utils`
   --> C:\Users\xxxku\.cargo\git\checkouts\rust-libraries-d71f37936ba3494c\91a9791\utils\src\commands\command_impl.rs:212:1

Meta

rustc --version --verbose:

rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-pc-windows-msvc
release: 1.83.0
LLVM version: 19.1.1

If the error message would contain any indication, why they are different, I would consider this a minor issue, but like this the error message claim they are different, and same at same time, so apart from actually resolving them correctly to same type, if another part of the build chain considers them to be same, because they are in same folder/file.

[jieyouxu]

I'm going to transfer this to the cargo issue tracker, as this looks like a cargo concern.

@rustbot transfer cargo

[weihanglo]

Mind sharing a minimal reproducible example? It is not clear what the "same build tree" means.

It might be a reexport issue though.

[xNxExOx]

cargo tree --features "debug"
proxy v0.0.1 (D:\rs\proxy)
├── bf_utils v0.1.0 (D:\rs\proxy\bf_utils)
│   ├── sr_libs v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a97919#91a97919)
│   │   └── utils v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a97919#91a97919) (*)
├── skylords_reborn_bot_api_types_rust v0.1.0 (https://gitlab.com/skylords-reborn/skylords-reborn-bot-api-rust.git?rev=de258ccc#de258ccc)
│   └── sr_libs v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a9791#91a97919)
│       └── utils v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a9791#91a97919) (*)
├── sr_libs v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a97919#91a97919) (*)
├── sr_packet v0.0.1 (D:\rs\proxy\sr_packets)
│   ├── from_server v0.0.1 (D:\rs\proxy\from_server)
│   │   └── sr_packet_utils v0.0.1 (D:\rs\proxy\sr_packet_utils)
│   │       └── sr_libs v0.1.0 (https://gitlab.com/skylords-reborn/rust-libraries?rev=91a97919#91a97919) (*)

this is pruned output of cargo tree.

sr_libs is shown there multiple times, all of these second level crates are part of same workspace, and use same dependency apart from skylords_reborn_bot_api_types_rust which is in different repository, so it needs its own Cargo.toml with definition of sr_libs.

The two lines was from skylords_reborn_bot_api_types_rust and the proxy's workspace dependency list.

Simplified example would be:

crate d2 (commit hash 123456789):

struct Whaever;

crate d1 (commit hash: aaaaaaaaa):

d2 = { rev = "12345", git = "https://gitlab.com/.../d2" }

fn eat(whatever: d2::Whaever) {}

crate binary:

d1 = { rev = "aaaaaaaaa", git = "https://gitlab.com/.../d1" }
d2 = { rev = "123456", git = "https://gitlab.com/.../d2" }

let whatever =  d2::Whaever;
d1::eat(whatever);

because the rev refers to same commit they will be the same on file system, and on git, but different when compiling and checking types, I guess because "12345" is different from "123456", even if they uniquely identify same commit.

@weihanglo is this explanation good enough, or do I need to create 3 public git repositories to showcase this?

[weihanglo]

Ah! I didn't notice your original post already has a difference between 91a97919 and 91a9791. Then this looks like a duplicate of #7497.

Cargo sees them as from different sources. For myself I recommend using the full hash. Not only because it is unambiguous and helps unify Git sources, internally Cargo leverages it to speedup fetches on GitHub. (I understand you're using GitLab and may not benefit from it though)

Anyway, thanks for the example. I'll close this and in favor of #7497. If there is a reason keeping this open separately, please let us know.

[xNxExOx]

Sure thank you, I did not find that one, when looking if it already exist, because it seems like mine being only 1 special case while #7497 is way more general.

[weihanglo]

BTW, if you heavily use GitLab and happen to know a similar git-fetch fast path for GitLab, please share and we could perhaps implement it!

[xNxExOx]

I almost never use it from console, so I have no idea, and I consider all repositories I use to be relatively small.