Open
Description
#6308 added a check if multiple jobs produce the same files. To be safe, it is currently a warning. At some point in the future it should be turned into a hard error if no problems are reported. Collisions are almost certainly bad behavior that will cause problems, so rejecting it is probably the right thing to do.
Related issues:
- Warn on duplicate artifact creation #5524: Request to warn on duplicate artifact creation — wherein
.rmeta
files started to collide because bin targets started producing them, and were corrupting one another if built simultaneously..rmeta
collisions fixed in Don't hardlink rmeta files. #6292. - What to do about duplicate targets in a workspace? #6293: Handling multiple targets in a workspace with the same name.
- Race condition when trying to compile a lib multiple times for different purposes. #5444: Hardlink collisions when target is built multiple times (like panic/no-panic). Fixed by Be more conservative about which files are linked to the output dir. #5460 by only hardlinking what was requested.
Known situations where collisions may occur:
- Multiple binary/example/lib targets in a workspace with the same name. (Or reusing a shared target directory.)
- Using
--out-dir
with an example and binary with the same name. - Multiple path dependencies with dylibs with the same name.
- Multiple dependencies with the same name and you select both of them on the command-line, for example:
cargo build -p rand:0.4.3 -p rand:0.5.5
. - rustdoc in a workspace where multiple crates have the same name. This can arise from a variety of situations (renamed dependencies, multiple versions of a package, different packages with the same crate names, etc.). (Multiple crates with the same name lead to conflicting
target/doc/crate
directories rust#56169, rustdoc: builds including multiple crates with the same name are always dirty rust#61378) panic="abort"
and cdylibs and tests: Create a project with a lib (cdylib crate type), binary, and an integration test, withpanic="abort"
in the profile. Whencargo test
runs, the cdylib is built twice (once with panic=abort for the binary, and once without for the test), with the same filename. Building the lib for the test should probably skip thecdylib
crate type (assuming rlib is also available), but implementing this is very difficult. See Duplicate artifact tracking issue. #6313 (comment).- Multiple targets (particularly executables) that differ only by case on case-insensitive filesystems.
- PDB collisions on Windows. If the package has a binary and a dylib library of the same name, then the
.pdb
file for each target will have the same name. This is easy to hit if you have a proc-macro package with a binary. - Dylib built multiple times with different features
- for example with new feature resolver, see Undefined symbols for x86_64 when using resolver="2" #9278.
- and with workspace members, see Fingerprint of dependency in workspace changes when running
cargo build
andcargo build -p <crate>
#12345
- Shared cdylib built with different profile settings, such as a build script and release mode Duplicate artifact tracking issue. #6313 (comment)
Notes on implementation issues:
- Cargo is hard-coded with the outputs that rustc produces. If those outputs change, it will not be able to catch those changes. In particular, Warn on duplicate artifact creation #5524 would not have been caught by these checks.
OutputFile
is currently not calculated correctly in some cases. Known issues:Debug files (likeFixed in Rework rustc output file tracking. #8210.dSYM
) are not tracked in some cases becauseTargetInfo::file_types
is making decisions about what should be hardlinked too early.- It is also very likely that it is missing certain platform differences.
Doc outputs are not tracked correctly (it generates incorrect paths).Fixed in Catch filename output collisions in rustdoc. #6998.Doctests generate incorrect paths. This should be fixed.Fixed in Catch filename output collisions in rustdoc. #6998, doc tests do not have any output paths.
- Not all outputs are checked. Such as:
- The
.d
dep info file. This uses the same hash as the main artifact, so is unlikely to be a problem. - Incremental files. One hopes that the hashes used in rustc are good enough?
- Other temp files created by rustc, like
rcgu
files, which should always include the hash. - Anything done by build scripts.
- The
cargo doc
has a dedicated path for detecting collisions. Ifcargo doc
is ever updated to support multiple crates with the same names, this code path can be removed.