-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rustdoc test compiler output color #74293
Rustdoc test compiler output color #74293
Conversation
color=always seems wrong -- we should try to thread the color status of rustdoc into rustc, rather, I suspect. In particular that should fix the tests here which shouldn't contain the ANSI codes (at least because I think that'll be a problem on Windows). |
I expected the executed |
rustc cannot handle that correctly -- you've told it to emit color independently of the normal heuristic. The normal heuristic doesn't work because stdout/stderr are connected to a pipe rather than the tty, so the detection concludes that colored output isn't the right choice. |
So we definitely have to rely on internal checks. @ehuss said that the only issue would be on older windows, so it has be taken into account. So to sum things up: I need to add a check to see that we're in a mode where colors are expected and that we're not on a too old windows. |
149a69e
to
2e37e4b
Compare
I'm concerned this approach doesn't work for a few cases, such as not connected to a TTY, or on older versions of windows. The only way I can think of to handle this properly is to query the Emitter. There's a lot of plumbing to get that information out, but seems to be the best way. Since JSON is currently not supported, I'll ignore it for now, but it should probably be supported someday. I would expect:
|
I looked at how |
ANSI support was added in Windows 10 Creators Update (mid 2017). here is where termcolor queries if ANSI is supported. The |
8b6eb7f
to
7a5a446
Compare
Updated! |
src/librustdoc/test.rs
Outdated
compiler.arg("--color").arg("always"); | ||
} | ||
} | ||
#[cfg(not(windows))] | ||
{ | ||
compiler.arg("--color").arg("always"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is missing the check that this is a TTY in both the windows and non-windows case. That's why I was suggesting to query the Emitter which has already figured these things out (and to avoid duplicating that logic).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Emitter
doesn't provide such information, that's why I had to add these checks performed in termcolor
. I didn't see something in librustc_errors that allowed me to know: "can I print color here?". But maybe I just missed it? If you have a tip, it'd be very helpful!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would need to be added as a new method to Emitter
.
For EmitterWriter
, it would need to check the Destination
to determine whether or not the destination supports color. For Terminal(StandardStream)
, it would check supports_color
. For Buffered(BufferWriter)
, it would need to call buffer().supports_color()
. For Destination::Raw
, it would be the 2nd tuple value (the bool indicating color support).
For JsonEmitter
, it would need to call new_emitter
and do the same checks as above.
Other emitters would need similar treatment, though I think the rest of them are special (like SilentEmitter
which could just return false).
This comment has been minimized.
This comment has been minimized.
There's merge conflict now. @GuillaumeGomez |
7a5a446
to
ccd2639
Compare
This comment has been minimized.
This comment has been minimized.
Add a comment why `extern crate` is necessary for rustdoc r? @ehuss From rust-lang#74293 (comment).
Add a comment why `extern crate` is necessary for rustdoc r? @ehuss From rust-lang#74293 (comment).
☔ The latest upstream changes (presumably #79104) made this pull request unmergeable. Please resolve the merge conflicts. Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:
|
… the color escape characters
bdcd6da
to
ec10824
Compare
@bors: r=jyn514 |
📌 Commit ec10824 has been approved by |
Rollup of 8 pull requests Successful merges: - rust-lang#74293 (Rustdoc test compiler output color) - rust-lang#78702 ([self-profiling] Include the estimated size of each cgu in the profile) - rust-lang#79069 (Get rid of `highlight::Class::None`) - rust-lang#79072 (Fix exhaustiveness in case a byte string literal is used at slice type) - rust-lang#79120 (update rustfmt to v1.4.27) - rust-lang#79125 (Get rid of clean::{Method, TyMethod}) - rust-lang#79126 (Remove duplicate `Trait::auto` field) - rust-lang#79130 (extend macro braces test) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
@GuillaumeGomez How do we prevent regression for this? |
Good question 😆 I'm open to ideas! |
The most accurate but hardest way is probably snapshot testing, like taking the image snapshot of the colors. Maybe we can just set the environment variables, and detect the colors ascii codes in standard output? |
@pickfire would you be interested in working on that? That sounds like we might even be able to put it in |
No, not for this. I have quite a few backlog I want to do and never did. |
Thanks for fixing this @GuillaumeGomez! I know I was being a little picky that it properly supports all versions of Windows, but I think good Windows support is important, and I appreciate that you took the time to get it working. |
@ehuss You were right in doing so! If merged too quickly, we only get bugs later on. I personally don't use windows so input from windows users are very welcome. |
Fixes #72915
We just need to be sure it doesn't break rustdoc doctests' compilation checks. Maybe some other unforeseen consequences too?
r? @ehuss
cc @rust-lang/rustdoc