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

[Artem Dergachev via cfe-dev]

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's not going to break the source compatibility (apart from the few 
checks where people put their DiagnosticBuilder into a local variable, 
they'll have to change the type of that variable), but neither would it 
introduce a look-alike interface because it's still literally the same 
interface and it's already kind of expected to be polymorphic.

On 9/6/19 6:44 AM, Dmitri Gribenko wrote:
> On Wed, Sep 4, 2019 at 1:17 AM Artem Dergachev <noqnoqneo at gmail.com> wrote:
>> Clang-Tidy doesn't really need BugReporter; all it needs is
>> PathDiagnosticConsumer. (the word "Path" is rudimentary)
>>
>> It should be perfectly comfortable to build PathDiagnostics by hand - it
>> maps nicely to how you already build your warnings and notes.
> I like this approach better, however, I also think that
> PathDiagnostic's API is a lot more complex than the current `diag()
> <<` in ClangTidy. For example, it requires the caller to specify the
> checker name. It also requires to specify a ton of locations and
> decls, whereas we can probably infer most of the locations and decls
> from just one location.
>
> Again, something I would really like to see written down (and us agree
> upon) is the data model for a diagnostic. When we know what data we
> need to store, we can figure out how to store it, and a convenient API
> to populate it.
>
> 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>*/