Quuxplusone added a comment.
PVS-Studio implements tons of checks of this variety. See e.g.
http://www.viva64.com/en/b/0299/#ID0E4KBM
They don't have a catchy name for the category either, but perhaps
"suspicious-" or "copypaste-" would do.
I agree with Aaron that "thinko-" would be a little ina
aaron.ballman added a comment.
In https://reviews.llvm.org/D27815#626440, @Prazek wrote:
> The example of this kind of check is here:
> https://reviews.llvm.org/D27806
>
> I am not sure if it make sense to put it as clang warning.
>
> After a little bit of thinking I guess name "typos" would be
Prazek added a comment.
The example of this kind of check is here:
https://reviews.llvm.org/D27806
I am not sure if it make sense to put it as clang warning.
After a little bit of thinking I guess name "typos" would be better, because I
want to look for checks that are mostly typos (which are o
Quuxplusone added a comment.
The provided example (typoing "i" for "j") sounds like the sort of thing that
PVS-Studio catches; maybe see what wording they use for that kind of mistake?
Without investigating, I would suggest "cut-and-paste-error" or "likely-typo".
However, the attached patch *d
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,
Prazek added a comment.
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 shou
aaron.ballman added a comment.
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
Prazek added a comment.
In https://reviews.llvm.org/D27815#624322, @Eugene.Zelenko wrote:
> There are many other checks or compiler warnings which could be classified as
> obvious bugs.
Sure, but unfortunatelly they won't be able to become warning because of false
positive rate.
In the examp
Eugene.Zelenko added a comment.
There are many other checks or compiler warnings which could be classified as
obvious bugs.
https://reviews.llvm.org/D27815
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailma
Prazek added a comment.
In https://reviews.llvm.org/D27815#624294, @Eugene.Zelenko wrote:
> I'm not sure that this is good name for module.
>
> Singe reason for this is check for STL algorithms, may be //stl// module is
> more correct destination?
The reason for this module is that I want to m
Eugene.Zelenko added a comment.
I'm not sure that this is good name for module.
Singe reason for this is check for STL algorithms, may be //stl// module is
more correct destination?
https://reviews.llvm.org/D27815
___
cfe-commits mailing list
cfe-
Prazek created this revision.
Prazek added reviewers: alexfh, malcolm.parsons.
Prazek added a subscriber: cfe-commits.
Herald added subscribers: JDevlieghere, mgorny.
Module for checks for obvious bugs that probably won't be found
in working code, but can be found while looking for an
obvious bug
12 matches
Mail list logo
