[PATCH] D38455: [clang-tidy] new cppcoreguidelines-narrowing-conversions check.

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

In https://reviews.llvm.org/D38455#1062722, @courbet wrote:

> In https://reviews.llvm.org/D38455#1062718, @JonasToth wrote:
>
> > > Sure. Is it OK to add a dependency from clang-tidy/bugprone/BugproneTidyModule.cpp to stuff in clang-tidy/cpp-coreguidelines ? Is there an existing example of this ?
> >
> > Take a look in the hicpp module, almost everything there is aliased :)
>
>
> Thanks for the pointer !


We currently don't have any strict rules about aliases, but we should remember that aliases have certain costs (in terms of maintenance and possible user-facing issues like duplicate warnings from different checks). I think that in general it would be better to avoid excessive aliases. There are cases when aliases are inevitable (or at least feel like a proper solution), like when multiple style guides have the same rule or very similar rules that make sense to be implemented in a single check with a bit of configurability to easily accommodate the differences. But in this case there's so far one specific rule of the C++ Core Guidelines that the check is enforcing, and adding an alias under bugprone- for it seems to be unnecessary. I also think that if a user wants to enable this check, they'd better know that it backs up a rule of the C++ Core Guidelines rather than being just an invention of clang-tidy contributors (there's nothing wrong with the latter, it's just nice to give credits where appropriate ;).

I suggest to try applying the following decision process to find proper place(s) for a check:

1. List all use cases we want to support, decide whether customizations (via check options) will be needed to support them. Use case may be
  - enforcement of a rule of a certain style guide a clang-tidy module for which exists or is being added together with the check;
  - generic use case not covered by a rule of a style guide. These only count if there is no "style guide" use case that doesn't require customizations.

2. If the check only has a single "style guide" use case, place it to the corresponding module.
3. If a check (without customizations) implements rules of two or more style guides, and dependency structure allows, place it to one of the corresponding modules and add aliases to the others.
4. Otherwise choose a "generic" module for the check (bugprone-, readability-, modernize-, performance-, portability-, or misc-, if the check doesn't suit a more specific module). Add aliases to the "style guide" modules, if needed.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D38455