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.
Details
Diff Detail
Event Timeline
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."? |
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. |
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. |
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.
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..." |
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. |
clang-tidy/ClangTidyOptions.h | ||
---|---|---|
93 | A bool parameter in ErrorReporter ctor seems good. |
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/)
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).
I think this can be simplified to: