[cfe-dev] RFC: Pumping Clang-Tidy warnings through the Static Analyzer's BugReporter.

[Artem Dergachev via cfe-dev]

As i've been vaguely hinting on EuroLLVM, i plan to invest some time in 
decreasing the gap between Clang-Tidy users and Static Analyzer users 
and make sure it's always possible for our users to take the best of 
both worlds. In particular, i'd like to make Clang-Tidy easily 
integratable into all UIs that already integrate the Static Analyzer. 
The opposite is already true because Clang-Tidy links to the Static 
Analyzer. However, existing Static Analyzer users (eg., users that rely 
on Scan-Build for their build system interception or use the Static 
Analyzer through Xcode) cannot easily take advantage of Clang-Tidy. 
Also, as far as i understand, Ericsson CodeChecker currently performs 
ad-hoc integration of Clang-Tidy by parsing text output, which most 
likely works just fine, but definitely contributes to anxiety. On the 
other hand, the BugReporter facility of the Static Analyzer has a 
variety of output modes, including fancy html reports and 
machine-readable plist output, so if we pump Clang-Tidy reports through 
the same BugReporter it'll open up some new possibilities.

Ideally i'd love to do the same to Clang-Tidy that Clang-Tidy does to 
us: make the Static Analyzer load it as a library and expose Clang-Tidy 
checks as its own, maybe in a separate package. This is harder to do 
though, because Clang-Tidy lives in a separate repo and also it's a hard 
sell to build it into the Clang binary. I'm open to suggestions here: we 
can keep such integration under an off-by-default CMake flag (which 
requires enabling compilation of clang-tools-extra) or we may even use 
it as a run-time plugin (i mean, clang plugins are super wonky, but this 
time it's actually fairly easy to avoid version conflicts, as they all 
get compiled from the same sources simultaneously).

But regardless of how far do i end up going with such integration, first 
thing first: i'll anyway need to teach Clang-Tidy how to route its 
diagnostics through our diagnostic engine. This is also the only thing 
that's absolutely necessary; the rest can always be hacked up on the UI 
side.

It's a great question why didn't we extend Clang's DiagnosticEngine to 
begin with, but instead made our own facility. I don't know the answer 
to that; this happened way before i even learned what an AST is :) We 
generally needed a much more sophisticated diagnostic engine because our 
reports are much more complicated. While we could try to unify these 
diagnostic engines completely, i don't think it's worth it.

So i think it's more feasible to make Clang-Tidy's diag() method return 
a proxy object that mimics the DiagnosticBuilder interface but may also 
pump the diagnostics to an instance of the Static Analyzer's 
BugReporter. I hope this would avoid API breakages for clang-tidy checks.

It is going to be a bit annoying that DiagnosticBuilder treats warnings 
and their respective notes as completely unrelated diagnostics, while 
for the purposes of the BugReporter they need to be on the same 
BugReport object. I should be able to take care of this on the 
BugReporter side as long as clang-tidy checkers promise to always emit 
notes immediately after their respective warnings (which seems to be the 
case, but i didn't look at *all* the checks).

Finally, one feature that BugReporter was lacking until recently was the 
fix-it hint support. However, this is mostly out of the way since 
https://reviews.llvm.org/D65182.

Does any of that sound reasonable? Should i proceed with this?