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

[Aaron Ballman via cfe-dev]

On Fri, Dec 23, 2016 at 12:25 PM, Piotr Padlewski via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
>
> 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.

I think that this approach ignores the behavior users are used to
seeing from diagnostics in the frontend from Clang (though this is the
approach used by other compilers, like Visual Studio). Having used
this scheme in MSVC for years, I strongly prefer the way Clang and GCC
control their diagnostics, where groupings are only for logically
related diagnostics rather than a broad categorization. I've found the
way MSVC does things to be problematic in practice; for instance, in
LLVM, we enable a specific warning level, but then have to manually
disable a dozen+ diagnostics that don't quite fit our needs.

~Aaron

>
> Piotr
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>