[PATCH] D27815: [clang-tidy] Add obvious module for obvious bugs

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In https://reviews.llvm.org/D27815#625271, @Prazek wrote:

> In https://reviews.llvm.org/D27815#625102, @aaron.ballman wrote:
>
> > I am really not keen on the name "obvious" for this module. What is obvious to one person is not always obvious to another. Also, if the checks are finding *obvious bugs*, then that suggests they should be implemented in the clang frontend rather than a tool that is run less frequently.
> >
> > Since the checks are meant to be finding bugs rather than enforcing a coding standard, performance, readability, etc, a few possible alternative names:
> >
> > `bugs-`
> >  `correctness-`
>
>
> My intention is to have kind of bugs that you facepalm when you find it. Mostly simple typos.
>  As I said this can't make it to clang because it would have some false positives.


Many warnings in clang have some false positives. Do you envision these having a fairly high false positive rate, or expensive to check for?

> I am ok with making group like `bugs` that would have some checks that are curently in misc (misc-use-after-move), but still, this group would be special in the sense that it looks for very simple bugs that you can make during coding, but you won't be able to find it in code that seem to work.

I'm having a hard time imagining how many checks would be in this module from that description. Are you expecting to move items from misc to populate this module (if so, which ones, aside from misc-use-after-move?), or are you intending to add some checks we don't currently have (if so, can you list a few of them)? From your description, it sounds like these are not obvious bugs (since the code seems to work and the bugs are hard to spot), but it may be that "bugs" or "correctness" could also be a poor name. With some examples of checks that could go in the module, we may be able to pick a more appropriate name.


https://reviews.llvm.org/D27815