This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] Add a -show-color flag.
Needs RevisionPublic

Authored by itessier on Jan 3 2018, 3:55 PM.

Details

Summary

This change will allow enabling of colour diagnostics when not directly running within a terminal, but colour output is possible. For example, if stdout is being captured and redirected to a real terminal.

Diff Detail

Event Timeline

itessier created this revision.Jan 3 2018, 3:55 PM
Eugene.Zelenko set the repository for this revision to rL LLVM.

This patch is missing test coverage.

clang-tidy/ClangTidy.cpp
99–101

I think this can be simplified to:

DiagOpts->ShowColors = Context.getOptions().ShowColor.getValueOr(llvm::sys::Process::StandardOutHasColors());
clang-tidy/tool/ClangTidyMain.cpp
150–152

I think this raw string can be reflowed a bit?

Instead of "defaults to on", how about "Defaults to true when a color-capable terminal is detected."?

itessier updated this revision to Diff 128652.Jan 4 2018, 2:33 PM
itessier marked an inline comment as done.

This patch is missing test coverage.

Done.

clang-tidy/tool/ClangTidyMain.cpp
150–152

I copied that part from the -fcolor-diagnostics flag to be consistent. I don't changing "on" to "true" if you prefer that instead.

alexfh requested changes to this revision.Jan 5 2018, 6:06 AM

Clang supports -fcolor-diagnostics. I guess, we could use it, e.g. via -extra-arg=-fcolor-diagnostics.

clang-tidy/ClangTidyOptions.h
93

This doesn't belong to ClangTidyOptions. It's specific to the CLI, but CLI is not the only frontend for clang-tidy.

This revision now requires changes to proceed.Jan 5 2018, 6:06 AM
alexfh added a comment.Jan 5 2018, 6:50 AM

Clang supports -fcolor-diagnostics. I guess, we could use it, e.g. via -extra-arg=-fcolor-diagnostics.

On a second thought, configuring the colors using -extra-arg doesn't seem like a good solution to me. A separate command line option is fine, but it should be just a frontend option independent of ClangTidyOptions.

jhasse added a subscriber: jhasse.Jan 16 2018, 7:23 AM
itessier added inline comments.Jan 26 2018, 2:25 PM
clang-tidy/ClangTidyOptions.h
93

Since we have to propagate the value to the ErrorReporter, how about adding a bool param to the ErrorReporter ctor? We could add a setter instead, but that would require moving a diag printer call out of the ctor since it uses the DiagOpts instance.

The colour logic would then be moved into either clangTidyMain or handleErrors.

clang-tidy/tool/ClangTidyMain.cpp
150–152

That should have read "I don't mind changing..."

aaron.ballman added inline comments.Jan 29 2018, 5:04 AM
clang-tidy/tool/ClangTidyMain.cpp
150–152

I'd say let's go ahead and change it, and once this patch lands, change the help text for -fcolor-diagnostics in a follow-up.

alexfh added inline comments.Jan 31 2018, 1:25 AM
clang-tidy/ClangTidyOptions.h
93

A bool parameter in ErrorReporter ctor seems good.

alexfh added inline comments.Jan 31 2018, 1:33 AM
test/clang-tidy/show-color.cpp
7

nit: I'd prefer to depend on the wording and format of static analyzer warnings only where necessary. Static analyzer is in a different repository and when it changes, it's a bit more difficult for folks to detect failures in clang-tidy. Here we could use any native clang-tidy check instead.

What are you thoughts about using an environment variable for this? Due to the number of differently named flags, it's often hard to configure a CI system to display color in every tool. (I'm trying to push for a standard for this, see https://bixense.com/clicolors/)

Any update on this?

As a workaround, you can use a standalone utility called unbuffer from Tcl/Tk's expect bundle. Just put it in front of the clang-tidy invocation. In case you use run-clang-tidy, you can put invocation.insert(0, 'unbuffer') right above proc = subprocess.Popen(invocation, stdout=subprocess.PIPE, stderr=subprocess.PIPE).