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?