When sharing CARGO_TARGET_DIR, cargo does not distinguish between 2 path deps with the same name/version

[codyps]

Problem

When one sets CARGO_TARGET_DIR to a directory shared between different workspaces, if those workspaces include crates that are path dependencies with the same name and version and relative-to-the-workspace-path (ie: from the root of the workspace, these crates are in the same place, even though in system-wide terms they are separate directories), cargo treats these 2 crates as the same.

This results in potentially unexpected crates being combined for anyone using a shared CARGO_TARGET_DIR.

Steps

I've made a repo showing the issue here: https://github.com/jmesmon/cargo-rebuild-bug

Running ./test.sh does 2 cargo builds: crates a and b with a shared CARGO_TARGET_DIR. a has a path dependency on c (located at a/c). b has a path dependency on c (located at b/c). The crate in a/c has an pub unsafe fn c() -> u32, while b/c has a pub fn c() -> u32 (ie: safe). This fails on the second build when it tries to build b, which should depend on b/c, but instead tries to use a/c, and an error about calling an unsafe function is emitted.

./test-working.sh shows the same 2 crates built without sharing a CARGO_TARGET_DIR.

Possible Solution(s)

Plausible that the metadata for path crates (relative to a parent crate/workspace) needs to include some extra info, perhaps some part of path (or a fully resolved path) that would be sufficient to distinguish them.

Alternately, one might at least ensure a rebuild occurs (but still possibly break some things) by detecting that the content of a/c and b/c don't match, triggering a rebuild.

Notes

No response

Version

cargo 1.72.0-beta.8 (44b6be4bd 2023-08-03)
release: 1.72.0-beta.8
commit-hash: 44b6be4bdf2cd7d3f4d4cb266bfe428dfc2a7952
commit-date: 2023-08-03
host: x86_64-apple-darwin
libgit2: 1.6.4 (sys:0.17.2 vendored)
libcurl: 7.88.1 (sys:0.4.63+curl-8.1.2 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Mac OS 13.4.0 [64-bit]

[weihanglo]

This could be the source of the issue: Cargo uses relative paths to identify sources of path dependencies.

cargo/src/cargo/core/source/source_id.rs

Lines 466 to 485 in 3a34fca

	/// Hashes `self`.
	///
	/// For paths, remove the workspace prefix so the same source will give the
	/// same hash in different locations, helping reproducible builds.
	pub fn stable_hash<S: hash::Hasher>(self, workspace: &Path, into: &mut S) {
	if self.is_path() {
	if let Ok(p) = self
	.inner
	.url
	.to_file_path()
	.unwrap()
	.strip_prefix(workspace)
	{
	self.inner.kind.hash(into);
	p.to_str().unwrap().hash(into);
	return;
	}
	}
	self.hash(into)
	}

[IceTDrinker]

Hello,

Just to chime in on this and indicate I am hitting this behavior, it seems it is not appending any sort of fingerprint to the artifact name which is done when compiling crates coming from the crate.io repo, if help is needed on this I can lend a hand as it's creating a discrepancy between path and crate dependencies which I'm not sure would be warranted in that case

Cheers