-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate artifact tracking issue. #6313
Comments
I have an interesting scenario where we are getting this warning that feels a little like a false positive. We have a project that we can build with
Now the why for us doing this has to do more with either nuances or our misunderstandings of how the
The same warnings happen for bin targets as well. The two things seemingly being compared in this case aren't created by different targets/build. |
@kamathba Can you clarify some things about your use case for me? I'm trying to understand why you are using |
@ehuss I think its mostly because of us using both the All that said, I'm more wondering why cargo can't elide when the --out-dir is the same as the directory it was going to place things in anyways? As I'm digging into this answer, I'm wondering why our builds default to building for x86_64-unknown-linux-musl even though we don't specify it in .cargo/config. We'd like to not use --out-dir, as its one of the only reasons we aren't on stable now that clippy/rustfmt landed. |
As described here I have a crate in which I'd like to produce both a This seems impossible at the moment. Specifically, Cargo writes both dylibs to the same filename i.e. it seems to write one and then it seems to overwrite it with the other (can't tell you which is which without digging into the final file though). |
I'm trying to produce Also, |
@Lokathor Can you share a minimum example to demonstrate? I'm not sure how to reproduce your issue. Also, which platform are you on? |
how about a build log? the same general warning happens for the mac build too, which you can also find there on windows, https://ci.appveyor.com/project/Lokathor/thorium/builds/23603097/job/sia07tfchtthym5a (im not 100% sure this is the exact same commit, but it should be) I don't know how to make a more minimal example. I actually don't even care except for the scary warning that it might become an error later. |
@Lokathor OK, I see what is happening. It is a consequence of having cdylib and I can't think of an easy workaround for you, unfortunately. I'm not sure what the best approach here is. Perhaps dylibs could be placed in unique directory names. Also, maybe Cargo could be more conservative what it builds for tests, since it is only linking against one lib type. |
I only need the dylib for Unfortunately, cargo features are currently quite boring and cannot control much. What I would like is if features could control more. |
Catch filename output collisions in rustdoc. This does some general cleanup so that rustdoc output is computed correctly. This allows the collision detection code to work. There are some known issues with rustdoc creating collisions (rust-lang/rust#61378, rust-lang/rust#56169). This is related to issue #6313. This includes a change that `CompileMode::is_doc` no longer returns `true` for doc tests. This has bothered me for a while, as various points in the code was not handling it correctly. Separating it into `is_doc` and `is_doc_test` I think is better and more explicit. Note for reviewing: There is a big diff in `calc_outputs`, but this is just rearranging code. Everything in `calc_outputs_rustc` is unchanged from the original. The only functional changes should be: - A warning is emitted for colliding rustdoc output. - Don't create an empty fingerprint directory for doc tests.
If you are going to make something a terminating error, could you please make sure that the message sets out the steps that we programmers should follow to fix the error. Otherwise it is like "You have been bad. Compilation prohibited. Goodbye." and then you get all these issues and forum posts. |
Documenting Servo produces lots of warnings like: warning: output filename collision.
The lib target `parking_lot` in package `parking_lot v0.8.0` has the same output filename as the lib target `parking_lot` in package `parking_lot v0.7.1`.
Colliding filename is: /repo/target/doc/parking_lot/index.html
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>. This simply becoming a hard error is not acceptable. Having multiple crates with the same name in the dependency graph is a use-case that Cargo needs to support. Even this warning arguably should not exist: this situation is normal, it’s up to Cargo and rustdoc together to figure something out. |
In this type of reasoning, please consider: who’s behavior is bad? Who is responsible to fix it? Warnings and errors are only appropriate when the end user is responsible. Even if the current output is arguably wrong/incomplete, erroring would be a regression. |
@SimonSapin It is a bug. This won't become a hard error until most of the bugs are resolved. Part of the reason of this warning is to ferret out these bugs. Currently it is randomly stomping on files depending on which goes first, so the current behavior is wrong. This warning is just letting you know something is wrong. We can reword the warning to convey "this is a bug" in the situations where it is a bug. It might be difficult to detect some of the scenarios. Unfortunately fixing the rustdoc case will be difficult. I think it will require significant changes to rustdoc in order to restructure the directory layout, and have cargo communicate to rustdoc how to link to multiple versions. |
Adjust warning for rustdoc filename collision. The existing warning was a little misleading, as this is a known bug, not something we currently plan to reject. cc #6313 (comment)
I am curious is there a way to select which one of the colliding packages should be used in the doc gen in case of being in a secondary dependency especially if they are two different versions of the same package? The logs seem to suggest both packages got documented. But only the first one seems to be there. Is there something more to it? |
@ehuss Yes, rewording would be good. As a user of
This message is very strongly suggesting that I did something wrong and I should consider changing the names of "targets". (What are targets in this context? Do I even have any control over them?) But there is nothing wrong with having multiple versions of the same crate in a dependency graph. Cargo was designed from the very beginning to support that scenario. So it is not users who are doing something wrong, but the historical design of For an eventual fix, maybe Until then, yes then emitting a message to warn users of the data loss is better the silently overwriting. But blaming users (with a "we’ll break your stuff" threat!) is very much not the right response. |
Unfortunately, no. The one that appears in the final output can be random. |
@SimonSapin Can you explain which situation generated that message with
That is the fix, someone just needs to work on it. It is non-trivial, and requires changes to |
Avoids this problem warning: output filename collision. The bin target `schema` in package `vault-manager v0.1.0 (vault-manager)` has the same output filename as the bin target `schema` in package `epoch-manager v0.1.0 (epoch-manager)`. Colliding filename is: The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see <rust-lang/cargo#6313>.
I don't have this error with rust nightly 2024-06-24, but I've the issue with 2024-07-11. Worst, the warning ends up with an error in a build script because of the filename collision. I don't find any issues mentioning this so far. |
This comment was marked as off-topic.
This comment was marked as off-topic.
This avoids the error due to duplicated target names, as the binary `hugr` has the same name as the main library `hugr`. `cargo doc` showed this warning: ``` warning: output filename collision. The bin target `hugr` in package `hugr-cli v0.1.4 (/home/runner/work/hugr/hugr/hugr-cli)` has the same output filename as the lib target `hugr` in package `hugr v0.8.0 (/home/runner/work/hugr/hugr/hugr)`. Colliding filename is: /home/runner/work/hugr/hugr/target/doc/hugr/index.html The targets should have unique names. This is a known bug where multiple crates with the same name use the same path; see <rust-lang/cargo#6313>. ``` This caused the resulting docs to produce non-deterministic output, with either target overriding the other. See [cargo#6313](https://www.github.com/rust-lang/cargo/issues/6313).
Having two identically named binaries is a warning at the moment and will probably become an error at a later point. See also: rust-lang/cargo#6313
The `crypto` crate is linking old versions of the trait crates, and that's causing collisions when building the workspace rustdoc: warning: output filename collision. The lib target `aead` in package `aead v0.6.0-rc.0 (/Users/tony/src/RustCrypto/traits/aead)` has the same output filename as the lib target `aead` in package `aead v0.5.2`. Colliding filename is: /Users/tony/src/RustCrypto/traits/target/doc/aead/index.html The targets should have unique names. This is a known bug where multiple crates with the same name use the same path; see <rust-lang/cargo#6313>. warning: output filename collision. The lib target `cipher` in package `cipher v0.5.0-pre.7 (/Users/tony/src/RustCrypto/traits/cipher)` has the same output filename as the lib target `cipher` in package `cipher v0.4.4`. Colliding filename is: /Users/tony/src/RustCrypto/traits/target/doc/cipher/index.html The targets should have unique names. This is a known bug where multiple crates with the same name use the same path; see <rust-lang/cargo#6313>. This changes the CI config to exclude it from the rustdoc build for now, since everything else is on a prerelease series. We should probably bump `crypto` to link the latest prereleases soon, but for now this gets CI green again.
The `crypto` crate is linking old versions of the trait crates, and that's causing collisions when building the workspace rustdoc: warning: output filename collision. The lib target `aead` in package `aead v0.6.0-rc.0 (/Users/tony/src/RustCrypto/traits/aead)` has the same output filename as the lib target `aead` in package `aead v0.5.2`. Colliding filename is: /Users/tony/src/RustCrypto/traits/target/doc/aead/index.html The targets should have unique names. This is a known bug where multiple crates with the same name use the same path; see <rust-lang/cargo#6313>. warning: output filename collision. The lib target `cipher` in package `cipher v0.5.0-pre.7 (/Users/tony/src/RustCrypto/traits/cipher)` has the same output filename as the lib target `cipher` in package `cipher v0.4.4`. Colliding filename is: /Users/tony/src/RustCrypto/traits/target/doc/cipher/index.html The targets should have unique names. This is a known bug where multiple crates with the same name use the same path; see <rust-lang/cargo#6313>. This changes the CI config to exclude it from the rustdoc build for now, since everything else is on a prerelease series. We should probably bump `crypto` to link the latest prereleases soon, but for now this gets CI green again.
warning: output filename collision. The lib target `pocketclient` in package `pocketclient-mock v0.1.0 (~/3l/mock/pocketclient)` has the same output filename as the lib target `pocketclient` in package `pocketclient v0.1.0 (~/3l/pocketclient)`. Colliding filename is: ~/3l/target/debug/libpocketclient.rlib The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see <rust-lang/cargo#6313>.
warning: output filename collision. The lib target `pocketclient` in package `pocketclient-mock v0.1.0 (~/3l/mock/pocketclient)` has the same output filename as the lib target `pocketclient` in package `pocketclient v0.1.0 (~/3l/pocketclient)`. Colliding filename is: ~/3l/target/debug/libpocketclient.rlib The targets should have unique names. Consider changing their names to be unique or compiling them separately. This may become a hard error in the future; see <rust-lang/cargo#6313>.
Just got linked to this issue when running Edit: in both instances it's for a lib-only package where the manifest lists both "lib" and "rlib" in its |
Due to a bug in cargo the docs of nethsm-cli would overwrite those of nethsm. Prevent this by selectively generating docs and moving relevant dirs around. Related-to: rust-lang/cargo#6313 Signed-off-by: David Runge <[email protected]>
#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:
.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.Known situations where collisions may occur:
--out-dir
with an example and binary with the same name.cargo build -p rand:0.4.3 -p rand:0.5.5
.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)..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.cargo build
andcargo build -p <crate>
#12345Notes on implementation issues:
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.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..d
dep info file. This uses the same hash as the main artifact, so is unlikely to be a problem.rcgu
files, which should always include the hash.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.The text was updated successfully, but these errors were encountered: