rustdoc clashing output name hard error build failure regression

[ijackson]

I have several crates in my project. In particular, I have a library crate otter and a binary crate otter-cli which generates a binary called otter.

# ./Cargo.toml
[package]
name="otter"
[workspace]
members=["cli", "wasm", "daemon", "wdriver", "apitest"]
# library crate

and

# cli/Cargo.toml
[package]
name="otter-cli"
[dependencies]
otter.path=".."
[[bin]]
name="otter"
path="otter.rs"

I recently updated my rust frrom an old nightly to a recent one.

Now I get this error message:

error: document output filename collision
The bin `otter` in package `otter-cli v0.7.1 (/home/ian/Rustup/Game/server/cli)` has the same name as the lib `otter` in package `otter v0.7.1 (/home/ian/Rustup/Game/server)`.

It suggests using doc = false. I thought I could do that for the cli crate since the rustdocs for a command line program are generally not very useful. But if I do that none of the dependencies specific to the otter-cli crate get documented by cargo doc --workspace.

The correct fix would be to rename the rustdoc output file. But I don't think there is a way to do that. I don't think I can change the crate name for the cli to be different to the binary name. I don't want to change the main otter crate's idea of its own crate name.

I think it was unfortunate to make this a hard error before there was a better workaround.

rustc --version --verbose:

binary: rustc
commit-hash: e4a60327063e82413eed50a10df3b7d19b77bda0
commit-date: 2021-06-07
host: x86_64-unknown-linux-gnu
release: 1.54.0-nightly
LLVM version: 12.0.1

ISTM that this would be a regression from stable to stable for some projects. (Not mine because unfortunately I'm not able to build on stable at all right now.)

I think it might bite anyone who has a separate binary cli crate which generates a binary whose name is the same as their library crate. That doesn't seem to me to be a wholly unreasonable situation.

[inquisitivecrystal]

@rustbot label +A-rustdoc +T-rustdoc

[ehuss]

Transferred to the cargo repo, as this is an issue with cargo.

This change was unintentional (part of #9526). I didn't realize that would change existing behavior. I'll look into finding a way to keep the old behavior.

[ijackson]

Thanks for looking into it!