Skip to content
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

Merged

Conversation

GuillaumeGomez
Copy link
Member

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

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 13, 2020
@Mark-Simulacrum
Copy link
Member

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).

@GuillaumeGomez
Copy link
Member Author

I expected the executed rustc to handle that internally through its own termcolor. However, it might indeed be a good idea to not display colors if rustc isnt always or auto. I'll update.

@Mark-Simulacrum
Copy link
Member

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.

@GuillaumeGomez
Copy link
Member Author

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.

@GuillaumeGomez GuillaumeGomez force-pushed the rustdoc-test-compiler-output-color branch 2 times, most recently from 149a69e to 2e37e4b Compare July 14, 2020 12:44
@ehuss
Copy link
Contributor

ehuss commented Jul 14, 2020

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:

  • Windows consoles without virtual terminal processing should always be --color=never.
  • --color=always translates to --color=always
  • --color=never translates to --color=never
  • --color=auto will translate to always or never depending on if the emitter has detected color support.

@GuillaumeGomez
Copy link
Member Author

I looked at how termcolor was doing and apparently, old windows console seem to support ansi color codes, this is why I didn't make the check.

@ehuss
Copy link
Contributor

ehuss commented Jul 15, 2020

ANSI support was added in Windows 10 Creators Update (mid 2017). here is where termcolor queries if ANSI is supported. The is_synchronous function is probably the best way to detect if this is the case.

@GuillaumeGomez GuillaumeGomez force-pushed the rustdoc-test-compiler-output-color branch from 8b6eb7f to 7a5a446 Compare July 16, 2020 15:02
@GuillaumeGomez
Copy link
Member Author

Updated!

src/librustdoc/lib.rs Outdated Show resolved Hide resolved
Comment on lines 317 to 323
compiler.arg("--color").arg("always");
}
}
#[cfg(not(windows))]
{
compiler.arg("--color").arg("always");
}
Copy link
Contributor

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).

Copy link
Member Author

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!

Copy link
Contributor

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).

@ollie27 ollie27 added the T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. label Jul 24, 2020
@bors

This comment has been minimized.

@crlf0710 crlf0710 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 21, 2020
@crlf0710
Copy link
Member

There's merge conflict now. @GuillaumeGomez

@GuillaumeGomez GuillaumeGomez force-pushed the rustdoc-test-compiler-output-color branch from 7a5a446 to ccd2639 Compare August 22, 2020 15:44
@bors

This comment has been minimized.

@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. A-doctests Area: Documentation tests, run by rustdoc and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 15, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request Sep 16, 2020
Add a comment why `extern crate` is necessary for rustdoc

r? @ehuss

From rust-lang#74293 (comment).
tmandry added a commit to tmandry/rust that referenced this pull request Sep 16, 2020
Add a comment why `extern crate` is necessary for rustdoc

r? @ehuss

From rust-lang#74293 (comment).
@camelid camelid added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 7, 2020
@bors
Copy link
Contributor

bors commented Nov 17, 2020

☔ 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:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 17, 2020
@GuillaumeGomez GuillaumeGomez force-pushed the rustdoc-test-compiler-output-color branch from bdcd6da to ec10824 Compare November 17, 2020 09:33
@GuillaumeGomez
Copy link
Member Author

@bors: r=jyn514

@bors
Copy link
Contributor

bors commented Nov 17, 2020

📌 Commit ec10824 has been approved by jyn514

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 17, 2020
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 17, 2020
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
@bors bors merged commit 81f9feb into rust-lang:master Nov 17, 2020
@rustbot rustbot added this to the 1.50.0 milestone Nov 17, 2020
@GuillaumeGomez GuillaumeGomez deleted the rustdoc-test-compiler-output-color branch November 17, 2020 18:00
@pickfire
Copy link
Contributor

@GuillaumeGomez How do we prevent regression for this?

@jyn514
Copy link
Member

jyn514 commented Nov 18, 2020

Good question 😆 I'm open to ideas!

@pickfire
Copy link
Contributor

pickfire commented Nov 18, 2020

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?

@jyn514
Copy link
Member

jyn514 commented Nov 18, 2020

@pickfire would you be interested in working on that? That sounds like we might even be able to put it in rustdoc-ui without too many changes to the testing framework.

@pickfire
Copy link
Contributor

No, not for this. I have quite a few backlog I want to do and never did.

@ehuss
Copy link
Contributor

ehuss commented Nov 23, 2020

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.

@GuillaumeGomez
Copy link
Member Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-doctests Area: Documentation tests, run by rustdoc S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cargo doc test not colored