Ability to suppress "Generated" lines from cargo doc

[kpreid]

Problem

Since Rust 1.75, when cargo doc is run without --open, it prints "Generated <path>" for each documented crate in the workspace (#5562). While this is useful when users wish to open the documentation by some other means than --open, it's clutter (~doubling the height of the output) in a large workspace when the user already has the documentation open or has other means to access the path the documentation will be generated at.

Proposed Solution

Add a configuration option which suppresses “Generated” lines.

Alternatively, make cargo doc emit only one such line for the entire workspace, in the same way that cargo doc --open picks one path; this could be an option or might even be acceptable as the default behavior.

Notes

--quiet is not an adequate solution since it hides all output, including progress when re-documenting dependencies from clean.

The reason I personally care about this is that running cargo doc is part of my normal development cycle — if I don't run it, I won't discover I've broken an intra-doc link, which happens very often. So, I want the output to be short if nothing is wrong, but still let me see progress. (If cargo check reported broken intra-doc links and other doc lints, that would be an even better alternative, but I don't expect that to be feasible.)

[epage]

For myself, I am very cautious when it comes to adding configuration as it increases the combinations of what could fail and balloons documentation, making it harder to find any other piece of related documentation, making it less likely to use any feature, lowering the value gained from those features.

In #12859, I was originally going to show only one "Generated" line but was worried about only showing one package and it confusing the user. This is different than --open where they are immediately shown the web page and see the other packages. With "Generated", the user may never follow the link or may get confused before they follow the link.

For cargo script, I've been considering finding a way to collapse down the amount of output from cargo but that only helps with everything before "Generated".

One option might be if we add a trailing "and X other packages" to the "Generated" line? And then in verbose mode, we instead print them all?

[weihanglo]

One option might be if we add a trailing "and X other packages" to the "Generated" line? And then in verbose mode, we instead print them all?

If the status message of cargo doc won't be cached, this seems to be a good option. One thing to consider is that cargo test --no-run does a similar output printing Executable but hasn't got feedback like this. Should their behaviors be consistent with each other?

    Finished test [unoptimized + debuginfo] target(s) in 1m 02s
  Executable unittests src/cargo/lib.rs (target/debug/deps/cargo-52e5c7b69d837521)
  Executable tests/build-std/main.rs (target/debug/deps/build_std-aaec4da60de65b74)
  Executable tests/testsuite/main.rs (target/debug/deps/testsuite-3610deb6673c6f79)

[epage]

Funny you mention that for cargo test because I want to clean up all of that :)

[kpreid]

For myself, I am very cautious when it comes to adding configuration as it increases the combinations of what could fail and balloons documentation,

Which is why I mentioned a few other options (perhaps less straightforward, but not requiring configuration).

Perhaps I should just live with the disadvantage of --quiet.

One thing to consider is that cargo test --no-run does a similar output printing Executable but hasn't got feedback like this. Should their behaviors be consistent with each other?

Probably --no-run is used less often (or, at least, it certainly is by me). To me it makes sense that it works the way it does because if I'm doing a --no-run I might be intending to do something with the executables. (The last time I had reason to think about it, I was telling someone else that they could discover the executable path that way, in order to run the test under a debugger.) cargo doc's current behavior makes sense under the same logic. Perhaps the difference here is in what is the default behavior, and that cargo test by default is much more verbose (the Running lines are swamped by test harness output).