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

[Artem Dergachev via cfe-dev]

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.

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'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>*/
>