Cargo Doc Output Filename Collision

[dricross]

Problem

Unsure if this is a cargo issue or rust compiler issue.

cargo doc started yielding the follow error when using the nightly-2021-10-14 compiler or later:

error: document output filename collision
The lib `child-a-macros` in package `child-a-macros v0.1.0 (/home/dricross/git/cargo-doc-collision-minimal/crates/child-a/macros)` has the same name as the lib `child-a-macros` in package `child-a-macros v0.1.0 (/home/dricross/git/cargo-doc-collision-minimal/crates/child-a/macros)`.
Only one may be documented at once since they output to the same path.
Consider documenting only one, renaming one, or marking one with `doc = false` in Cargo.toml.

I am working with a monorepo which combines several crates using a virtual workspace. Key configuration items that appear to cause this issue:

• Virtual workspace containing a crate containing a proc-macro crate.
• Target specified in workspace configuration file.
• Any level of optimizations enabled.
• Certain compiler versions used, starting at least as early as nightly-2021-10-14.

Prior compiler versions do not exhibit this behavior.

Minimal repository demonstrating this issue: https://github.com/dricross/cargo-doc-collision-minimal

Steps

1. Clone this repository: https://github.com/dricross/cargo-doc-collision-minimal
2. Run cargo doc
3. Encounter error

Possible Solution(s)

No response

Notes

• Changing specified toolchain to nightly-2021-10-13 causes cargo doc to succeed
• Removing the [build] section of configuration file and running cargo doc --target x86_64-unknown-linux-gnu will succeed.
• Changing opt-level in dev profile to 0 will cause cargo doc to succeed. cargo doc --release will continue to fail.
  • Any non-zero opt-level will fail.
• rustc version nightly-2021-10-14 is the first to display this behavior for x86_64-unknown-linux-gnu and armv7r-none-eabihf targets. Prior nightly rustc versions will display this behavior when x86_64-apple-darwin is specified in the [build] section of configuration file

Version

cargo 1.57.0-nightly (d56b42c54 2021-09-27)
release: 1.57.0
commit-hash: d56b42c549dbb7e7d0f712c51b39400260d114d4
commit-date: 2021-09-27

or

cargo 1.57.0-nightly (c7957a74b 2021-10-11)
release: 1.57.0
commit-hash: c7957a74bdcf3b11e7154c1a9401735f23ebd484
commit-date: 2021-10-11
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.79.1-DEV (sys:0.4.49+curl-7.79.1 vendored ssl:OpenSSL/1.1.1l)
os: Ubuntu 20.04 (focal) [64-bit]

[holly-hacker]

This still seems to be an issue on nightly-2022-10-27.

For people that are encountering this, an alternative solution to setting opt-level to 0 is to add doc = false to the [lib] section of your proc-macro crate. It seems that documentation for such crates aren't generated anyway.

[wmmc88]

This still seems to be an issue on nightly-2022-10-27.

For people that are encountering this, an alternative solution to setting opt-level to 0 is to add doc = false to the [lib] section of your proc-macro crate. It seems that documentation for such crates aren't generated anyway.

documentation for proc-macro crates actually does work, but there is a cargo bug that causes them not to generate if you explicitly pass it a --target arg (even if you specify the same triple as host)

A better workaround, if you still want to generate proc-macro crate docs when not passing a target triple is to explicitly exclude the proc-macro crate when running cargo doc with --target: cargo doc --target <triple> --workspace --exclude <proc-macro crate>