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

[Artem Dergachev via cfe-dev]

On 9/12/19 4:55 AM, Dmitri Gribenko wrote:
>> 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?

Wait, we already have that? Nice! Will go that way then.

>
> 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
>