nightly-2024-04-12 selects incorrect version of git dependency

[itsjunetime]

Problem

When using the nightly-2024-04-12 toolchain, the exact revision of a git dependency is sometimes selected incorrectly. The compiler will state that it is compiling the correct revision (read: the version specified in the Cargo.toml) of this git dependency, but when invoked with -v, it will show that it's compiling a different version of this git dependency. This discrepancy can be shown in the following lines of output from cargo +nightly-2024-04-12 check:

Checking taffy v0.3.11 (https://github.com/DioxusLabs/taffy?rev=1876f72bee5e376023eaa518aa7b8a34c769bd1b#1876f72b)
     Running `/home/june/.rustup/toolchains/nightly-2024-04-12-aarch64-unknown-linux-gnu/bin/rustc --crate-name taffy --edition=2021 /home/june/.cargo/git/checkouts/taffy-3438f0b42e7e0e0f/1876f72/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata -C opt-level=3 -C embed-bitcode=no -C debuginfo=1 -C split-debuginfo=unpacked -C debug-assertions=on --cfg 'feature="alloc"' --cfg 'feature="block_layout"' --cfg 'feature="default"' --cfg 'feature="flexbox"' --cfg 'feature="grid"' --cfg 'feature="std"' --cfg 'feature="taffy_tree"' -C metadata=048e8c05f35f33a6 -C extra-filename=-048e8c05f35f33a6 --out-dir /home/june/Documents/coding/foss/zed/target/debug/deps -C linker=/usr/bin/clang -L dependency=/home/june/Documents/coding/foss/zed/target/debug/deps --extern arrayvec=/home/june/Documents/coding/foss/zed/target/debug/deps/libarrayvec-2cf3a94fcab00243.rmeta --extern grid=/home/june/Documents/coding/foss/zed/target/debug/deps/libgrid-a137abe40adf6338.rmeta --extern num_traits=/home/june/Documents/coding/foss/zed/target/debug/deps/libnum_traits-8d147377c4a58f30.rmeta --extern slotmap=/home/june/Documents/coding/foss/zed/target/debug/deps/libslotmap-9a779c33d9d94bff.rmeta --cap-lints allow -C link-arg=-fuse-ld=/usr/bin/mold`

You can see here that it says it's checking revision 1876f7, but actually invokes rustc on the checkout revision 3438f0.

I checked previous versions of the nightly toolchain, and this issue does not appear on anywhere between 2024-04-08 - 2024-04-11, so it was probably introduced in the 2024-04-12 version.

I haven't got a minimal reproduction working, but this issue was found by:

1. Cloning the zed repo
2. rm rust-toolchain.toml
3. cargo +nightly check

I have not tested it on any other repos (besides zed) or targets (besides aarch64-unknown-linux-gnu)

Steps

1. git clone https://github.com/zed-industries/zed.git
2. cd zed
3. rm rust-toolchain.toml
4. rustup install nightly-2024-04-12
5. cargo +nightly-2024-04-12 check

Possible Solution(s)

I don't know - I haven't yet identified what this could be caused by

Notes

I haven't yet tried to get a minimal reproduction - if it isn't easy to find the source of this, I'm happy to put some time into that.

Version

cargo 1.79.0-nightly (74fd5bc73 2024-04-10)
release: 1.79.0-nightly
commit-hash: 74fd5bc730b828dbc956335b229ac34ba47f7ef7
commit-date: 2024-04-10
host: aarch64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Fedora 39.0.0 [64-bit]

[weihanglo]

Have you cd to the directory and check if it is on the wrong commit?

The .cargo/git/checkouts/taffy-3438f0b42e7e0e0f/1876f72 path is structured as:

.cargo/git/checkouts/<pkg>-<hash-of-the-repo-url>/<commit-sha>

See also: https://doc.rust-lang.org/nightly/nightly-rustc/cargo/sources/git/source/struct.GitSource.html#filesystem-layout

[itsjunetime]

Thanks for pointing out the nested commit hash directory; that was confusing me initially and probably made my initial message somewhat confusing as I didn't understand the structure.

It looks like the 1876f72 directory is actually on the 1876f72 commit, both when I try to run this under nightly-2024-04-11 and nightly-2024-04-12 (the second one fails to build, the first doesn't). This may not be a cargo bug, then, but rather a rustc one. Feel free to close if you agree, I may make an issue there instead.

[itsjunetime]

Nevermind, it looks like this issue is the same as rust-lang/rust#123824 - I couldn't find it initially. Thanks for helping me to realize that :)