Skip to content

Cargo in Rust 1.66 changed location for source cache #11487

Closed as not planned
Closed as not planned
@jonhoo

Description

@jonhoo

Problem

In Rust 1.66.0, Cargo appears to be using a different hash for computing directory names in $CARGO_HOME/src/. This means that the cache from <=1.65.0 is no longer re-used. Furthermore, for anyone using Cargo as a library, if the version used as a library doesn't match the one used by the binary, they'll use different cache directories, causing everything to be extracted (and downloaded?) twice.

It doesn't appear to affect crates.io — not quite sure why. Do we hard-code its registry name somewhere perhaps?

Steps

$ rustup toolchain install 1.65.0
$ rustup toolchain install 1.66.0
$ cargo new cargo-version-hashing
$ cd cargo-version-hashing
$ echo 'serde = "1"' >> Cargo.toml
$ cargo generate-lockfile
$ mkdir .cargo
$ cargo local-registry -s Cargo.lock local-registry > .cargo/config.toml
$ env CARGO_HOME=$PWD/ch cargo +1.65.0 check
   Unpacking serde v1.0.150 (registry `/local/home/jongje/dev/tmp/cargo-version-hashing/local-registry`)
   Compiling serde v1.0.150
    Checking cargo-version-hashing v0.1.0 (/local/home/jongje/dev/tmp/cargo-version-hashing)
    Finished dev [unoptimized + debuginfo] target(s) in 4.18s
$ env CARGO_HOME=$PWD/ch cargo +1.66.0 check
   Unpacking serde v1.0.150 (registry `/local/home/jongje/dev/tmp/cargo-version-hashing/local-registry`)
   Compiling serde v1.0.150
    Checking cargo-version-hashing v0.1.0 (/local/home/jongje/dev/tmp/cargo-version-hashing)
    Finished dev [unoptimized + debuginfo] target(s) in 4.42s
$ exa -la ch/registry/src/
drwxr-xr-x - jongje 15 Dec 21:08 -168cb03ff00d48fc
drwxr-xr-x - jongje 15 Dec 21:08 -a4f4e04374b9ac0b
$ rm -rf ch
$ env CARGO_HOME=$PWD/ch cargo +1.65.0 check
   Unpacking serde v1.0.150 (registry `/local/home/jongje/dev/tmp/cargo-version-hashing/local-registry`)
    Finished dev [unoptimized + debuginfo] target(s) in 0.23s
$ env CARGO_HOME=$PWD/ch cargo +1.66.0 check
   Unpacking serde v1.0.150 (registry `/local/home/jongje/dev/tmp/cargo-version-hashing/local-registry`)
    Finished dev [unoptimized + debuginfo] target(s) in 0.24s
$ exa -la ch/registry/src/
drwxr-xr-x - jongje 15 Dec 21:09 -168cb03ff00d48fc
drwxr-xr-x - jongje 15 Dec 21:09 -a4f4e04374b9ac0b

Possible Solution(s)

The cause of this was #11209, which added a new variant to SourceKind, which in turn affects the derived impl Hash for SourceKind. That Hash impl is taken into account in impl Hash for SourceId here:

self.inner.kind.hash(into);

which in turn is used to generate a SourceId's "short name" here:

fn short_name(id: SourceId) -> String {
let hash = hex::short_hash(&id);
let ident = id.url().host_str().unwrap_or("").to_string();
format!("{}-{}", ident, hash)
}

I'm not 100% sure where crates.io diverges so it doesn't go through the same path, but it's definitely intentional given this test. I suspect it's because the crates.io SourceId is constructed specially:

pub fn crates_io(config: &Config) -> CargoResult<SourceId> {

Notes

No response

Version

cargo 1.66.0 (d65d197ad 2022-11-15)
release: 1.66.0
commit-hash: d65d197ad5c6c09234369f219f943e291d4f04b9
commit-date: 2022-11-15
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.15.0 vendored)
libcurl: 7.79.1 (sys:0.4.55+curl-7.83.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.6.1 [64-bit]

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-bugCategory: bugregression-from-stable-to-stableRegression in stable that worked in a previous stable release.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions