To be clear, I'm not referring to crate names conflicting with IDs in use by rustdoc — I'm referring to two crates having the same --crate-name.
This occurs when using cargo doc where
- Two versions of the same package are in the dependency tree, e.g.
radium = "0.7"andradium = "1.0" - Two different packages set the same
lib.name, e.g.forked-oldlibsetslib.name = "oldlib"to make migration just a manifest change - A local workspace crate has both a library and a binary target without custom names
Other than for this lint, the main thing rustdoc would utilize the other identifying information for is disambiguation when there's a crate name conflict. docsrs does its postprocessing to separate out multiple versions of package docs, putting docs at /package/version/crate/.
Rustdoc probably doesn't need to do anything like this, and cargo doc might take some of the responsibility (since cargo knows the package tree but rustdoc doesn't), but it's certainly beneficial for the package and version number to be available in the docs, even if they're not used to detect conflicts.
If documenting a library crate's dependency graph and that crate has multiple documented binary targets, it's probably more helpful to present the binaries differently than the libraries; perhaps nested under the library crate they're attached to, but at least somehow differentiated from the library crates, since they have no public API. (Binaries get documented with --document-private-items by default. cargo doc will document at least both the library and default binary target if they have distinct names.)
If cratespaces become a thing, that absolutely will need to be visible in the docs.