This patch adds --use-color command line option and UseColor option to clang-tidy to control colors in diagnostics. With these options, users can force colorful output. This is useful when using clang-tidy with parallelization command line tools (like ninja and GNU parallel), as they often pipe clang-tidy's standard output and make the colors disappear.
mostly good, just nits.
nit: ... wil be used if the terminal connected to standard output supports colors, or even simple if missing, it will be auto detect.
nit: just use-color
nit: set cl::init(false)
Address the comments above.
I also removed the incorrect DefaultOptions.ColorDiagnostics = ColorDiagnostics in ClangTidyMain.cpp. That produces incorrect UseColor: false with -dump-config.
I'm not entirely sure this option belongs in the config file. However if it will get read in here, maybe update the help string for the command line option to say it overrides the UseColor option from the .clang-tidy configuration file.
It will be useful in the config file if the user invokes clang-tidy via another tool that does not allow the user to set clang-tidy's command line options.
I've updated it.
None of the clang-tidy command line options are prefixed with -f.
This command line option used to be --color-diagnostics, but I've followed @hokein's advice to change it to --use-color.
If you mean to use the -fcolor-diagnostics option from compile_commands.json, clang-tidy and clang are two separate tools. The users may not want them to share the same setting, because they may invoke them in different environments.
Fair point, will this option also control the color of the diagnostics emitted by clang or just clang tidy specific diagnostics?
This option sets DiagOpts->ShowColors to true. As I known, it controls all diagnostics reported by the clang-tidy program (by clang::tidy::(anonymous namespace)::ErrorReporter), including clang-diagnostic-* and other clang-tidy checks.
Would a test case be needed?
clang::tidy::clangTidyMain() shows that clang-tidy reports all diagnostics by clang::tidy::handleErrors(), which constructs a clang::tidy::(anonymous namespace)::ErrorReporter, no matter where they come from, so I think a test case is not required.
Not a fan of this test case as it only demonstrates the color behaviour of the process running the check not the actual option itself
What does "option itself" mean?
The standard output is always piped to FileCheck's standard input. It will never become "a terminal that supports color".
Standard error is not redirected explicitly, but it is not used to detect color support.