Passing '--all-features' flag to 'cargo doc' does not trigger rebuild

[Aaron1011]

Problem
When running cargo doc, adding or removing the --all-features flag does not cause docs to rebuilt. However, enabling or disabling features can affect the generated documentation if exported types/methods are behind a #[cfg(feature)].

Steps

1. Run cargo clean
2. Run cargo doc, and observe that Documenting <crate-name> is printed.
3. Run cargo doc --all-features, and note that Finished is immediately printed.

Possible Solution(s)
Changing the presence/absence of the --all-features flag should cause cargo doc to rebuild the docs for at least the current crate. A simple approach would be to rebuild docs for the entire dependency tree - a more sophisticated approach would be to only rebuild docs for crates dependencies affected by the changed features (e.g. dependencies that end up getting their enabled features changed as well).

Notes

Output of cargo version: cargo 1.39.0-nightly (22f7dd049 2019-08-27)

[ehuss]

It should work once. The crate needs to actually have a disabled feature for it to make a difference. There is an issue where swapping between them won't work unless the mtime of a source file is changed.

In Cargo.toml:

# …
[features]
foo = []

in lib.rs:

/// one
pub fn f() {}

#[cfg(feature="foo")]
/// two
pub fn foo() {}

1. cargo doc should build without foo.
2. cargo doc --all-features should build with foo.
3. cargo doc will not switch back, it is considered "fresh" when it is not.

I think the fix is to change this line to also return for is_doc(). This removes the metadata computation for rustdoc units, which I think is only being used for the fingerprint stem. This would force rustdoc units to all use the same fingerprint.

One thing that needs to be considered is if the fallback to bin_stem still makes sense. At the very least, that function should be renamed since it is used for more than just bins. I'm thinking it should probably include a little more in the hash, like the mode, I'm not sure.

There are also some complexities with rustdoc doing bin targets, particularly when there is a lib and bin of the same name (which is currently bugged if you say doc --lib --bins).

[ehuss]

See also #7961, with a similar issue but for features of a dependency.