[cfe-dev] [clang-tidy] Dealing with check names

Piotr Padlewski via cfe-dev cfe-dev at lists.llvm.org
Fri Dec 23 09:25:44 PST 2016


2016-12-23 18:05 GMT+01:00 Piotr Padlewski <piotr.padlewski at gmail.com>:

>
>
> 2016-12-23 17:57 GMT+01:00 Malcolm Parsons <malcolm.parsons at gmail.com>:
>
>> On 13 Dec 2016 12:45 p.m., "Piotr Padlewski" <piotr.padlewski at gmail.com>
>> wrote:
>>
>> I don't mind having google/llvm specific checks in list (as links).
>>
>>
>> I like the way clang-format handles this; the --style option allows
>> different organisations to have different default settings.
>>
>> How about removing the aliases and having --defaults={llvm,google,cert,cppcoreguidelines}
>> select a default set of checks and options.
>>
>> I really like this idea
>
>
>> --
>> Malcolm Parsons
>>
>
> Thinking more about it I think that we should come up with some new level
o categorization of check if we would like to make this tool very easy to
use.
I would like to have some kind of flag that would use some default checks,
that we know are useful for < 95% of users, have very little false
positives.
Each level (let say 4 levels like with optimizations) would have different
set of checks, where -W0 would be as good as -Wall in frontend (it would be
extended to checks that are useful but can't be in clang because analysis
would take too long). One check could be enabled in multiple levels with
different options, f.e.
modernize-loop-convert in -W0 would use MinConfidence: safe, and in -W1:
resonable and in -W3: risky.

I know that now we would have to get to consensus about which checks are
usefull on which level, but because the levels would be something that user
should not relay on, we could change the configuration every time someone
fix a bug or report a bug. And the same thing is in frontend (if warning
should go to -Wall or not) and people get to consensus what diagnostic is
good enough to be in which group.

Piotr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161223/46d0517b/attachment.html>


More information about the cfe-dev mailing list