<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>To clarify what I would like to propose:</p>
<blockquote>
<p>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.</p>
</blockquote>
I think there should be 2 parallel things: '<b>checks</b>' and '<b>guidelines</b>'.<br>
<br>
A 'guideline' is a collection of different checks and can combine
different domains. <br>
For example, a 'cppcoreguidelines'-guideline consists of
`modernize-use-auto,cppcoreguidelines-owning-memory,...`. Therefor i
think a 'guideline' is equivalent to a custom put together
configuration file.<br>
<br>
'checks' on the other hand remain the same, the actual code to
analyze, diagnose and maybe fix code.<br>
<br>
For the user the interface would be like this:<br>
<i>`clang-tidy -checks=cppcoreguidelines-* # the rest` = enable all
checks that are *directly* implemented for the cppcoreguidelines
(e.g. owning-memory)</i><i><br>
</i><i>`clang-tidy -guidelines=cppcoreguideline # the rest` = enable
all checks that are necessary to enforce the cppcoreguidelines
(e.g. use-auto and owning-memory)</i><i><br>
</i><i>`clang-tidy -guidelines=hicpp,cert # the rest` = enable
everything to ensure cert and hicpp compliance</i><br>
<br>
Given, that there are currently almost no aliases in clang-5 (only
some of the `hicpp-*` aliases land there) we could just ignore the
existing aliases and treat them like normal checks. There shouldn't
be many clashes with 'guidelines' activating them.<br>
<br>
The benefits are still: <br>
- Aliases are ugly to handle from our side<br>
- the source of warnings is not too obvious and it might occur that
the warnings are once reported as `hicpp-use-auto` and
`modernize-use-auto`<br>
- bad documentation, there is no high level view (50% of the
guideline is implemented, see here for general advice and so on)
like a status page<br>
- do not scale well. Having to maintain and keep track of
potentially hundreds of aliases is harder for the current form<br>
<br>
One current approximation for that approach would be custom
delivered configuration files, that would be activated by the
`-guidelines` - flag.<br>
I would be happy to deliver these for `hicpp` and
`cppcoreguidelines`, since i have done these pretty much already to
get an overview of whats already implemented.<br>
</body>
</html>