fix(rustdoc): Color doctest errors

[Muscraft]

@fmease's Deep analysis on the problem

Yeah, here's a deep analysis by me from a few weeks back of what's going on (#148101 (comment)):

[…]
However, since said PR (#147207: migrating coloring crates), HumanEmitter::supports_color() unconditionally(!) returns false (in fact, Emitter::supports_color is no longer used by anyone else and should be removed), so there's no reason to keep it. Rephrased, since that PR all compiler diagnostics for doctests are uncolored.
You could argue that I should keep it and patch supports_color in rustc to "work again". However, I'd rather rework our doctest coloring wholesale in a separate PR. At least before that migration PR, our setup was quite busted:

1. First of all, it didn't query+set supports_color for syntactically invalid doctests, so syntax errors were always shown without color (contrary to e.g., name resolution errors).
2. Second of all, calling supports_color() here was quite frankly wrong: Piping the output of rustdoc … --test into a file (or | cat or whatever) did not suppress colors. I'm not actually sure if we can ever address that nicely (without stripping ANSI codes after the fact) since we pass that diagnostic to libtest, right? I might very well be wrong here, maybe it's a non-issue.

---

/// ```
/// foo
/// ``` 
fn foo() {}

rustdoc --test lib.rs

Stable:

Beta:

Nightly:

After:

Note: This will need to be backported to beta

Fixes: #148749

[fmease]

Thanks, one small nit!

View changes since this review

[fmease]

I should've realized that much earlier: Obviously, like on stable, rustdoc bad-doctest.rs --test | cat / rustdoc bad-doctest.rs --test > file.txt still leads to colored output because libtest outputs this to stdout while we're querying stderr here.

I consider this a bug but I don't want it to be fixed in this PR since there are some subtleties. E.g., if you pass --no-capture (previously known as --nocapture) to rustdoc, then both output streams don't get captured meaning querying stderr would actually make sense in that specific case. There are probably some other things that need consideration.

[fmease]

I'll provide some more context for other T-rustdoc members. In my opinion to_color_choice as used in both rustc & rustdoc is suboptimal as it doesn't harness the full power of crate anstyle-query due to the fact that it yields Never if the config is Auto and stderr is not a terminal meaning NO_COLOR=1 works but e.g., CLICOLOR_FORCE=1 doesn't.

That's a separate bug I or Muscraft will deal with in the future, hopefully.

I'm saying all that because I originally wanted to use CLICOLOR_FORCE=1 in a potential regression test for #148749 which requires --color=auto (not --color=always) which obviously never leads to colored output since it's captured by compiletest, not by the terminal. I wanted to use CLICOLOR_FORCE=1 to indirectly test --color=auto (and have the golden file be an SVG or ANSI codes if that doesn't work out).

That's the reason why there's no regression test. If you have any other ideas, please let me know.

[fmease]

While this does touch the compiler, the changes aren't behavioral. Therefore I'll now remove the T-compiler label and nominate it for T-rustdoc only.

[fmease]

@bors rollup

r=me with #148834 (comment) addressed in one way or another

[fmease]

@bors r+

[bors]

📌 Commit c523b65 has been approved by fmease

It is now in the queue for this repository.

[fmease]

Beta backport accepted as per #t-rustdoc > beta-nominated: #148834 @ 💬.