<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I went through this process for the High Integrity Module, it was
very time consuming and annoying. <br>
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!<br>
<p>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.</p>
<p>My approach would be:</p>
- a status page (similar to C++17-Support page)<br>
- a 'built-in' yaml-Config file (.clang-tidy-cppcoreguidelines,
.clang-tidy-cert, ...)<br>
- multiple names for a check<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
```<br>
# say we want the coreguidelines and cert<br>
clang-tidy -get-config cppcoreguidelines # create
.clang-tidy-core-guidelines<br>
clang-tidy -get-config cert # create .clang-tidy-cert<br>
diff .clang-tidy-* # see the differences, do manual work<br>
```<br>
<br>
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).<br>
<br>
We would just provide multiple names for a check where currently
only one is allowed.<br>
<br>
What i am thinking of is going into this direction, its not a formal
proposal :)<br>
<br>
<div class="moz-cite-prefix">Am 25.09.2017 um 14:33 schrieb Gábor
Horváth:<br>
</div>
<blockquote type="cite"
cite="mid:CAPRL4a3HKELup8h0UWNjHLjQ3VCaYAkSeoiLQDA=DLsYNPp3Fg@mail.gmail.com">
<div dir="ltr">Hi!<br>
<div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 24 September 2017 at 18:53,
Jonas Toth via cfe-dev <span dir="ltr"><<a
href="mailto:cfe-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
everybody,<br>
<br>
i am currently trying to get an overview on the
implementation status of the CppCoreGuidelines in all
clang tools and especially clang-tidy.<br>
<br>
All rules with a section on enforcement are collected
here (<a
href="https://github.com/JonasToth/CppCoreGuidelinesTooling"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://github.com/JonasToth/<wbr>CppCoreGuidelinesTooling</a>),
and if possible there is the checkname for clang-tidy
etc. mentioned.<br>
<br>
The implementation status in short:<br>
<br>
number of rules:
286<br>
number of enforced rules: 123<br>
number of rules without enforcement: 163<br>
<br>
The reason I am writing this here: Most of the checks
that would enforce the guideline are not in the
`cppcoreguidelines-*`-list.<br>
<br>
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. </blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>Gábor<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">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-memor<wbr>y`. 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.<br>
<br>
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.<br>
<br>
A quick way to implement this: custom configuration
files directly shipped with clang-tidy.<br>
<br>
<br>
A discussion on that issue would be very nice! I am
willing to spent some time on an implementation for that
issue as well.<br>
<br>
<br>
All the best, Jonas<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank"
moz-do-not-send="true">cfe-dev@lists.llvm.org</a><br>
<a
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
</body>
</html>