rust-lang / rust-lang/cargo

Path dependencies leaving the workspace get hashed.

Open
#7,645 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

A-reproducibility C-bug S-needs-design
Dominant language
Rust
Stars
15.5k
Forks
3k
Avg merge
23h 30m
Merged PRs (30d)
51

Description

While trying to achieve full determinism builds in a complicated real-world setup, I noticed that the crate hashes (which show up in filenames and are passed to rustc in -C metadata=...) would change for crates which were referred to by relative paths, but which left the workspace.

Is this intentional? If so, I'm curious what the reasoning behind that is.

I could imagine a situation where two packages with the name and the same version could show up in the same dependency tree, but isn't that an error anyway?

Minimal example (using the eddyb/cargo-issue-7645-example repo):

# Initialize issue7645-{1,2}
git clone https://github.com/eddyb/cargo-issue-7645-example issue7645-1
cp -a issue7645-1 issue7645-2

# Build issue7645-1/{,nested/}
cargo build --manifest-path=issue7645-1/Cargo.toml
cargo build --manifest-path=issue7645-1/nested/Cargo.toml

# Build issue7645-2/{,nested/}
cargo build --manifest-path=issue7645-2/Cargo.toml
cargo build --manifest-path=issue7645-2/nested/Cargo.toml

# List all the copies of libfoo's that were built
find issue7645-{1,2}/{,nested/}target/debug/deps/libfoo-*.rmeta

On the current nightly, I get:

issue7645-1/target/debug/deps/libfoo-fd649d53ec9bad59.rmeta
issue7645-2/target/debug/deps/libfoo-fd649d53ec9bad59.rmeta
issue7645-1/nested/target/debug/deps/libfoo-1eae900464f3a413.rmeta
issue7645-2/nested/target/debug/deps/libfoo-467e958a8a02d00e.rmeta

As you can see, the top-level workspace builds have the same hash, but the nested workspace builds have a different hash, because foo is outside of that workspace (and has a different path).

cc @ehuss (with whom I've previously discussed this on Discord)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the linked eddyb/cargo-issue-7645-example repository and reproduce the four cargo build commands and libfoo hash comparison. Trace how Cargo handles path dependencies inside versus outside a workspace and how that affects rustc metadata. Done means determining whether the differing hashes are intentional and reaching a documented resolution or agreed behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, tooling
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.