macos: unreported filename collision with bin and dylib

[ehuss]

Problem
On macOS, if there is a project with a bin and a dylib (or cdylib), there is a filename collision with the dep-info file foo.d. Cargo does not detect this, and results in possible corruption of the fingerprint file. Since there is a race for writing the .d file, it is possible for both fingerprints to think they are pointing at main.rs or lib.rs.

Steps

cargo new foo
cd foo
cat <<EOF >> Cargo.toml
[lib]
crate-type = ["cdylib"]
EOF
touch src/lib.rs
cargo build

Notice there is only one .d file in target/debug/deps (foo.d). If you're unlucky, you may also notice that Cargo now thinks that both lib and bin are main.rs (cat target/debug/.fingerprint/foo-*/dep-*). That means that touch src/lib.rs && cargo build will have no effect.

Possible Solution(s)
Off the top of my head, I cannot think of how to solve this. For reasons, it cannot use -C extra-filename for both bins and dylibs. --emit can take paths like --emit dep-info=target/debug/deps/foo-somehash.d, so maybe that is an option. At a minimum, cargo should emit a warning that this is a known bug, similar to #6313.

Notes

Output of cargo version:

cargo 1.52.0-nightly (90691f2 2021-03-16)

[ehuss]

@rustbot claim

[weihanglo]

I tried to reproduce it but cannot with 1.58.1. I feel like this issue was already fixed coincidentally by #9418

Should we add a test to verify the behavior or just close it?

[ehuss]

Thanks for taking a look! Yea, I think this specific case for macos has been fixed. A test would be good to add. However, there are some edge cases to be careful of. The problem is this block of code. I think both msvc and wasm32-unknown-emscripten have other problems that get in the way (.pdb files for msvc and .wasm files for wasm). However, they also have silent .d filename collisions, too.

So the test won't work for msvc. I'm not sure if we need to try to track the .d files to be more defensive. Probably not? I'm not sure.

[weihanglo]

Thanks for the reply. I also noticed that. Besides adding a test, perhaps we can also emit warnings for those targets, and track them in #6313.

Edit: There are already collision warning there and the collisions are also tracked, so we only need to add a test to prevent any regression on macOS