[cfe-dev] RFC: Pumping Clang-Tidy warnings through the Static Analyzer's BugReporter.
Artem Dergachev via cfe-dev
cfe-dev at lists.llvm.org
Tue Aug 13 20:00:43 PDT 2019
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
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
Does any of that sound reasonable? Should i proceed with this?
More information about the cfe-dev