[cfe-dev] clang-tidy and CppCoreGuidelines

[Roman Lebedev via cfe-dev]

Hopefully i won't hijack this thread :)
Copying my related problem rant from https://reviews.llvm.org/D38171 here,
since this is basically the same problem as far as i can see:


On a somewhat related  note, since this is already talking about aliases

I feel like the current handling of the clang-tidy check aliases needs
adjusting.
If one enables all the checks (`Checks: '*'`), and then disables some of them
on check-by-check basis, if the disabled check has aliases
(`cppcoreguidelines-pro-type-vararg` vs `hicpp-vararg`, `hicpp-no-array-decay`
vs `cppcoreguidelines-pro-bounds-array-to-pointer-decay` and so on)
each of the aliases must be explicitly be disabled too.

This is rather inconvenient.

If that is intentional, perhaps there could be a config option to either disable
creation/registration of the check aliases altogether, or an option to threat
aliases as a hard link, so anything happening to any of the aliases/base check
would happen to all of them.

(Also, if the check has parameters, and one specifies different
parameters for the base check, and the aliases, what happens?)

A mail [0] posted by @JonasToth is about the similar problem, i think
we can continue there.

I *think* he has a point, a some better way to setup aliases, without actually
creating aliased checks is the solution IMO. This way, there won't be any
need to disable all the aliases when completely disabling the checks, and
there won't be multiple config options for the each alias. The legacy support
is the question though.

[0] (https://lists.llvm.org/pipermail/cfe-dev/2017-September/055589.html)



TLDR: if the check aliases are gone and no more, and some alternative way to
enable group of checks that implement part of some guidelines exists,
then i believe all of my problem points would be solved too.

Yes, i understand that legacy configs interoperability will need some though.

Roman.



On Sun, Sep 24, 2017 at 7:53 PM, Jonas Toth via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hello everybody,
>
> i am currently trying to get an overview on the implementation status of the
> CppCoreGuidelines in all clang tools and especially clang-tidy.
>
> All rules with a section on enforcement are collected here
> (https://github.com/JonasToth/CppCoreGuidelinesTooling), and if possible
> there is the checkname for clang-tidy etc. mentioned.
>
> The implementation status in short:
>
> number of rules:                                       286
> number of enforced rules:                        123
> number of rules without enforcement:     163
>
> The reason I am writing this here: Most of the checks that would enforce the
> guideline are not in the `cppcoreguidelines-*`-list.
>
> It would be very nice, if there is an easy way to enable all checks for the
> guideline, but adding ~100 aliases in clang-tidy is infeasable and since
> many rules would apply to other guidelines as well it isn't scalable, too.
> Such a change would mean, that sections like `readability, modernize,
> performance, ...` still exist standalone as well as especially for a
> guideline implemented checks like `cppcoreguideline-owning-memory`. But when
> running clang-tidy to enforce a guideline, clang-tidy would directly
> activate all checks necessary to do so, even if there is no alias in the
> related module.
>
> I would like to propose/discuss the possibility to have built-in
> configurations in clang-tidy, that would activate and configure all related
> checks. Such a feature would benefit other guidelines (High Integrity C++,
> CERT) and reduce duplication.
>
> A quick way to implement this: custom configuration files directly shipped
> with clang-tidy.
>
>
> A discussion on that issue would be very nice! I am willing to spent some
> time on an implementation for that issue as well.
>
>
> All the best, Jonas
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev