[cfe-dev] More plans on Static Analyzer + Clang-Tidy interoperation.

[Artem Dergachev via cfe-dev]

After a bit of hiatus i'm reviving this work. The previous discussion is 
at http://lists.llvm.org/pipermail/cfe-dev/2019-August/063092.html, also 
http://lists.llvm.org/pipermail/cfe-dev/2019-September/063229.html. The 
plan is not to turn the two Clang bug-finding tools into a single tool 
entirely but rather to make them more interchangeable, so that users who 
have existing integration of, say, static analyzer, could also have 
clang-tidy integration for as-free-as-possible. In particular, 
checks/checkers could be shared, which would resolve the constant 
struggle of "where to put the checker?".

One thing i realized since the last discussion is that the more tools we 
integrate, the more redundant compilation work do we perform. If we are 
to compile the code + run static analyzer + clang-tidy separately over 
it, that's 3 rebuilds of the AST from scratch. Whatever solution we 
provide to run both tools, I'd much rather keep it at 2 (compilation + 
*all* analysis) because static analysis is already expensive in terms of 
build-time, no need to make it worse.

One core component of this plan is to teach clang-tidy how to emit 
reports in various human-readable and machine-readable formats that the 
static analyzer already supports. At this point i'm pretty much ready to 
publish a clang::DiagnosticConsumer that'd produce all kinds of static 
analyzer-style reports. In particular, such consumer would enable 
clang-tidy to be used from inside scan-build instead of clang --analyze; 
both clang-tidy checks and static analyzer checkers would be ran from 
inside clang-tidy binary but produce html reports consumable by 
scan-build; a common index.html report would be generated for all 
checkers. I'm very much in favor of teaching scan-build how to run 
arbitrary clang tools, not just clang-tidy (i.e., "scan-build 
--tool=/path/to/my-clang-tool" or something like that) which would allow 
users who don't have CMake compilation databases to take advantage of 
clang tools more easily (and we have a few users who are interested in 
that).

On the other hand, we've also made up our mind that for ourselves we do 
in fact want produce a clang binary with clang-tidy checkers integrated. 
Apart from free integration into a number of our CI systems, that'll 
allow us to avoid shipping and supporting the clang-tidy command line 
interface as a separate feature. That's about 7MB increase in clang 
binary size which we're fine with. I plan to make it an off-by-default 
cmake flag unless there are strong opinions to do the opposite. The 
alternative approach to move ourselves into a separate binary that's 
integrated at the Driver level would also technically work but that's 
too disruptive to commit to for us at the moment - even just the Driver 
work alone would require a lot of testing, let alone making sure that 
static analyzer works exactly as before from within the tool (it already 
works from inside clang-tidy but we don't really know if it actually 
works *the same* in all the potential cornercases).

So, like, we want to support multiple workflows.

Also i'll be making occasional commits to some clang-tidy checks that 
we're interested in - mostly to address a few false positives (say, some 
checkers aren't aware of some Objective-C constructs), but also 
sometimes tweak the warning text a little bit (for example, 
bugprone-assert-side-effect is an awesome check but the warning text 
"found assert() with side effect" sounds fairly un-compiler-ish - we're 
not playing hide-and-seek!). Hope i'm welcome with these changes ^.^