[cfe-dev] clang-tidy and CppCoreGuidelines

[Jonas Toth via cfe-dev]

I went through this process for the High Integrity Module, it was very 
time consuming and annoying.
When introducing an alias you must create a new documentation, setup 
auto redirect in docs, ensure all links work and update the checker 
list. This took me for ~30 aliases a week almost fulltime (including 
figuring out what can be aliased and so on). This will create a lot of 
codereview noise as well!

A related issue is, that there are currently no status pages for the 
guidelines. To keep track of all these things is hard and more 
important, time consuming.

My approach would be:

- a status page (similar to C++17-Support page)
- a 'built-in' yaml-Config file (.clang-tidy-cppcoreguidelines, 
.clang-tidy-cert, ...)
- multiple names for a check

Both the status page and configuration must be kept in sync, and the 
status page would be the documentation, that links the check 
options/capabilities and the actual guideline.

At the moment I can only recall `readability-function-size, 
readability-identifier-naming` and maybe `modernize-use-auto` that would 
be candidates with conflicting configuration. Others might exist, but 
most checks aren't configurable.

Having builtin config-files would allow to resolve conflicts between 
coding standards, currently the user won't even notice that one is an 
alias to another/where the alias comes from.

```
# say we want the coreguidelines and cert
clang-tidy -get-config cppcoreguidelines # create 
.clang-tidy-core-guidelines
clang-tidy -get-config cert # create .clang-tidy-cert
diff .clang-tidy-* # see the differences, do manual work
```

Having a workflow like that, would integrate with the current 
implementation of config files and would be convenient for the users, 
since there are no flaky reports when activating too many aliases to the 
same checker (e.g. `modernize-use-auto` would be pretty much in every 
guideline with possibly different configuration).

We would just provide multiple names for a check where currently only 
one is allowed.

What i am thinking of is going into this direction, its not a formal 
proposal :)

Am 25.09.2017 um 14:33 schrieb Gábor Horváth:
> Hi!
>
> On 24 September 2017 at 18:53, Jonas Toth via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto: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
>     <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. 
>
>
> Why do you think it is not scalable or infeasible? If we introduce 
> built-in configurations we still need to maintain the "aliases" but in 
> different files. I see only one advantage here, when different 
> configurations are required by different aliases. But I do not know 
> how frequent such checks are.
>
> Regards,
> Gábor
>
>     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 <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170925/1e68afde/attachment.html>