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

[Alexander Kornienko via cfe-dev]

On Mon, Dec 12, 2016 at 4:02 PM, Piotr Padlewski <piotr.padlewski at gmail.com>
wrote:

> Hi,
> as clang-tidy grows there are more and more checks. One of the problem I
> see is that "misc" check group is not user friendly - there are many checks
> that do so many different things that usually user don't want to enable
> whole group.
>
Other groups like modernize, performance, google, cert, boost, llvm doesn't
> have this problem. Naturally the solution would be to split the group into
> smaller groups that would mean more.
>


Most checks in "misc" could be better described as "checks targeting
bug-prone patterns" and moved to a new module (e.g. "bugprone"). That would
make things better.


> The problem is that we should not change names because old configs will
> not work.
>

Following this logic, we should not add new checks or add/remove/change
check options, since some configs could stop working as they used to. Is
there an evidence of this being a serious issue?


>
> Do you have some ideas how we could fix it, so we could make it easier for
> users to use it?
>
> Other feature that we could add if we would know how to solve it is that
> we could make new groups that would mostly have aliases to other checks.
> This might be specially useful for cert checks - the cert code names
> doesn't tell anything, so it would be good to have these checks with proper
> name in different group so normal user could see what this check is doing
> from name and CERT users could run checks with cert group as it was before.
>

>

>
> One solution that I see is to reserve old name and make redirection, and
> maybe output warning about deprecated name when user would use special flag
> (e.g. verbose)
>

I personally don't think adding a deprecation mechanism for clang-tidy
checks is valuable. We could instead implement some form of validation of
check patterns (which could, for example, try to remove each part of the
glob list and see whether the resulting set of enabled checks changes).


>
> What do you think about this problem?
>
> Piotr
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20161221/80025d0c/attachment.html>