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

[Dmitri Gribenko via cfe-dev]

> On 10.09.2019 18:17, Artem Dergachev wrote:
> > Maybe i should do something similar to SemaDiagnosticBuilder, i.e.
> > sub-class DiagnosticBuilder and steal diagnostics from it in my
> > superclass destructor, so that to convert them to our path
> > diagnostics, WDYT?

That sounds like abuse of inheritance :) Subclassing DiagnosticBuilder
to hijack its output (which is stored in DiagnosticsEngine BTW!) is
too clever. The current Clang's diagnostics subsystem has a lot of
quirks already. I think diagnostics that start from DiagnosticBuilder
should be reported by DiagnosticsEngine to the DiagnosticConsumer.

If we want to reuse DiagnosticBuilder, WDYT about a custom
DiagnosticConsumer instead?

On Wed, Sep 11, 2019 at 6:26 AM Artem Dergachev <noqnoqneo at gmail.com> wrote:
>
> P.S. We could provide such diagnostic builder to our own AST-based
> checkers as well. That way we can see if it's indeed a better API for
> emitting path-insensitive warnings than BugReporter::EmitBasicReport(),
> which is pretty likely. And if so, i'll readily recommend it for use in
> any path-insensitive tool that emits warnings. This would also be an
> indication that our API is the best in long term.
>
> P.P.S. Such API would in its out-of-the-box shape not allow Clang-Tidy
> to add the typical path-sensitive pieces (event piece, control flow
> piece, etc.) to the report. But if you ever want to do this sort of
> stuff, it should be a matter of simply extending our superclass a little
> bit.

That does sound interesting, however, I'd prefer to try to figure out
ways to converge the two APIs (Clang's diagnostic subsystem and
BugReporter) instead of building more ways of doing the same stuff.
However, I'm not sure about the best way to do it. These APIs are
definitely built with different thoughts towards performance. Clang's
diagnostic subsystem is super-optimized to the point of trying hard to
not even dynamically allocate memory; all this while trying to present
an OOP interface, which, however, leaks the underlying implementation
by exposing the concepts of "in-flight diagnostic", "delayed
diagnostic" etc. Static Analyzer diagnostic subsystem is more OOP-like
in its implementation as well, with various path pieces for example.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/