Summary: Virtual function override near miss detection. Function complete. Test complete. Do not conduct Fix for now.
Reviewers: alexfh
Subscribers: cfe-commits
Patch by Cong Liu!
Differential Revision: http://reviews.llvm.org/D15823
llvm-svn: 257599
Summary: The new check will find all functionand variable definitions which may violate cpp one definition rule in header file.
Reviewers: aaron.ballman, alexfh
Subscribers: aaron.ballman, cfe-commits
Patch by Haojian Wu!
Differential Revision: http://reviews.llvm.org/D15710
llvm-svn: 257178
It is possible to assign arbitrary integer types to strings.
Sometimes it is the result of missing to_string call or apostrophes.
Reviewers: alexfh
Differential Revision: http://reviews.llvm.org/D15411
llvm-svn: 255630
ClangTidy check for finding cases when std::move() is called with const or
trivially copyable arguments, that doesn't lead to any move or argument but it
makes copy. FixIt generates patch for removing call of std::move().
Patch by Vadym Doroshenko! (+ a couple of minor fixes)
Differential Revision: http://reviews.llvm.org/D12031
llvm-svn: 254070
containers.
Summary:
sizeof(some_std_string) is likely to be an error. This check finds this
pattern and suggests using .size() instead.
Reviewers: djasper, klimek, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D12759
llvm-svn: 247297
Changes mostly address formatting and unification of the style. Use
MarkDown style for inline code snippets and lists. Added some text
for a few checks.
The idea is to move most of the documentation out to separate rST files and have
implementation files refer to the corresponding documentation files.
llvm-svn: 246169
Summary:
The existing check converts the code pattern below:
void f()
{
}
to:
void f()
override {
}
which is fairly sub-optimal. This patch fixes this by inserting the
override keyword on the same line as the function declaration if
possible, so that we instead get:
void f() override
{
}
We do this by looking for the last token before the start of the body
and inserting the override keyword at the end of its location. Note
that we handle const, volatile and ref-qualifiers correctly.
Test Plan: Includes an automated test.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9286
llvm-svn: 245401
Summary:
Support replacements in macro arguments in the
misc-inefficient-algorithm check.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11677
llvm-svn: 243747
As there don't seem to be a good way of formulating a matcher that
finds all pairs of functions and their ParmVarDecls, just match on
functionDecls and iterate over their parameters. This should also be
more efficient as some checks are only performed once per function.
llvm-svn: 243267
The parameters of the function templates were being marked as
incorrectly be marked as unused. Added a test for this and changed the
check to use the same
isReferenced() || !getDeclName()
logic as Sema::DiagnoseUnusedParameters.
Patch Scott Wallace, thank you!
llvm-svn: 242912
Enhance clang-tidy misc-macro-repeated-side-effects to handle ? and : better.
When ? is used in a macro, there are 2 possible control flow paths through the macro.
These paths are tracked separately so problems can be detected properly.
http://reviews.llvm.org/D10653
llvm-svn: 241245
Summary:
There were false positives in C++ code where macro argument was a type.
Reviewers: alexfh
Differential Revision: http://reviews.llvm.org/D10801
llvm-svn: 240938
The misc-static-assert check will not warn on the followings:
assert(NULL == "shouldn't warn");
assert(__null == "shouldn't warn");
Where NULL is a macro defined as __null.
llvm-svn: 236812
Summary:
Do not warn on .reset(.release()) expressions if the deleters are not
compatible.
Using plain assignment will probably not work.
Reviewers: klimek
Subscribers: curdeius, cfe-commits
Differential Revision: http://reviews.llvm.org/D8422
llvm-svn: 234512
Followup to http://reviews.llvm.org/D8465, which would break a test in
clang-tidy. clang-tidy previously assumes that source locations of
defaulted/deleted members are (incorrectly) not including the '= ...' part.
Differential Revision: http://reviews.llvm.org/D8466
llvm-svn: 233032
The misc-static-assert check will not warn on assert(false), assert(False),
assert(FALSE); where false / False / FALSE are macros expanding to the false or
0 literals.
Also added corresponding test cases.
http://reviews.llvm.org/D8328
Patch by Szabolcs Sipos!
llvm-svn: 232306
The patch was generated using this command:
$ clang-tidy/tool/run-clang-tidy.py -header-filter=.*clang-tidy.* -fix \
-checks=-*,llvm-header-guard clang-tidy.*
$ svn revert --recursive clangt-tidy/llvm/
(to revert a few buggy fixes)
llvm-svn: 231669
Classes are named WhateverCheck, files are named WhateverCheck.cpp and
WhateverCheck.h.
http://reviews.llvm.org/D8145
Patch by Richard Thomson!
llvm-svn: 231648
clang-tidy checks are organized into modules. This refactoring moves the misc
module checks into the namespace clang::tidy::misc
http://reviews.llvm.org/D7996
Patch by Richard Thomson!
llvm-svn: 230950
This patch contains two assert related checkers. These checkers are the part of
those that is being open sourced by Ericsson
(http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-December/040520.html).
The checkers:
AssertSideEffect:
/// \brief Finds \c assert() with side effect.
///
/// The conition of \c assert() is evaluated only in debug builds so a condition
/// with side effect can cause different behaviour in debug / relesase builds.
StaticAssert:
/// \brief Replaces \c assert() with \c static_assert() if the condition is
/// evaluatable at compile time.
///
/// The condition of \c static_assert() is evaluated at compile time which is
/// safer and more efficient.
http://reviews.llvm.org/D7375
Patch by Szabolcs Sipos!
llvm-svn: 230943
* Better error message when more than one of 'virtual', 'override' and 'final'
is present ("X is/are redundant since the function is already declared Y").
* Convert the messages to the style used in Clang diagnostics: lower case
initial letter, no trailing period.
* Don't run the check for files compiled in pre-C++11 mode
(http://llvm.org/PR22638).
llvm-svn: 230765
Algorithms like remove() does not actually remove any element from the
container but returns an iterator to the first redundant element at the end
of the container. These redundant elements must be removed using the
erase() method. This check warns when not all of the elements will be
removed due to using an inappropriate overload.
Reviewer: alexfh
Differential Revision: http://reviews.llvm.org/D7496
llvm-svn: 228679
Summary: Warn when the return type of assign operators is not Class&.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6667
llvm-svn: 228583
Summary:
Associative containers implements some of the algorithms as methods which
should be preferred to the algorithms in the algorithm header. The methods
can take advantage of the order of the elements.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7246
llvm-svn: 228505
Replace x.reset(y.release()); with x = std::move(y);
If y is rvalue, replace with x = y; instead.
http://reviews.llvm.org/D6485
Patch by Alexey Sokolov!
llvm-svn: 223460
Summary:
Register readability checks in a separate module. Renamed the checks
and test file names accordingly.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: curdeius, cfe-commits
Differential Revision: http://reviews.llvm.org/D5936
llvm-svn: 220631
Summary:
Some of the misc checks belong to readability/. I'm moving them there
without changing check names for now. As the next step, I want to register some
of these checks in the google and llvm modules with suitable settings (e.g.
BracesAroundStatementsCheck). I'm not sure if we want to create a "readability"
module, probably not.
Reviewers: djasper
Reviewed By: djasper
Subscribers: curdeius, cfe-commits
Differential Revision: http://reviews.llvm.org/D5792
llvm-svn: 219786
Add option ShortStatementLines to trigger this check only if the statement spans
over at least a given number of lines.
Modifications from the original patch:
merged test/clang-tidy/misc-braces-around-statements-always.cpp into
test/clang-tidy/misc-braces-around-statements.cpp and removed unnecessary
CHECK-NOTs from the tests.
http://reviews.llvm.org/D5642
Patch by Marek Kurdej!
llvm-svn: 219611
This check looks for if statements and loops: for, range-for, while and
do-while, and verifies that the inside statements are inside braces '{}'.
If not, proposes to add braces around them.
Example:
if (condition)
action();
becomes
if (condition) {
action();
}
This check ought to be used with the -format option, so that the braces be
well-formatted.
Patch by Marek Kurdej!
http://reviews.llvm.org/D5395
llvm-svn: 218898
As this is very dependent on the code base it has some ways of configuration.
It's possible to pick between 3 modes of operation:
- Line counting: number of lines including whitespace and comments
- Statement counting: number of statements within compoundStmts.
- Branch counter
In addition a threshold can be picked, warnings are only emitted when it is met.
The thresholds can be configured via a .clang-tidy file.
Differential Revision: http://reviews.llvm.org/D4986
llvm-svn: 217768
Summary:
Each check can implement readOptions and storeOptions methods to read
and store custom options. Each check's options are stored in a local namespace
to avoid name collisions and provide some sort of context to the user.
Reviewers: bkramer, klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5296
llvm-svn: 217661
parameter packs.
Summary:
This disables this check for std::bind and similar functions that use
parameter packs to forward arguments to a different function. Name of the
parameter pack argument doesn't matter.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5168
llvm-svn: 217039
Haven't thought that I ever needed to do this, but in this case comparing the
index using pointer arithmetic turns out to be really ugly. It also generates
nasty sign-compare warnings on 32 bit targets.
llvm-svn: 214705
Summary:
class Foo {
Foo() {
Foo(42); // oops
}
Foo(int);
};
This is valid code but it does nothing and we can't emit a warning in clang
because there might be side effects. The checker emits a warning for this
pattern and also for base class initializers written in this style.
There is some overlap with the unused-rtti checker but they follow different
goals and fire in different places most of the time.
Reviewers: alexfh, djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4667
llvm-svn: 214397
It doesn't make sense to suggest 'virtual' as clang-tidy would complain
about that on the next iteration (we are never issuing warnings for the
base function).
llvm-svn: 214063
ASTMatchers currently have problems mixing bound TypeLoc nodes with Decl/Stmt
nodes. That should be fixed soon but for this checker there we only need the
TypeLoc to generate a fixit so postpone the potentially heavyweight AST walking
until after we know that we're going to emit a warning.
This is covered by existing test cases.
Original message:
[clang-tidy] Add a check for RAII temporaries.
This tries to find code similar that immediately destroys
an object that looks like it's trying to follow RAII.
{
scoped_lock(&global_mutex);
critical_section();
}
This checker will have false positives if someone uses this pattern
to legitimately invoke a destructor immediately (or the statement is
at the end of a scope anyway). To reduce the number we ignore this
pattern in macros (this is heavily used by gtest) and ignore objects
with no user-defined destructor.
llvm-svn: 213738
Summary:
This tries to find code similar that immediately destroys
an object that looks like it's trying to follow RAII.
{
scoped_lock(&global_mutex);
critical_section();
}
This checker will have false positives if someone uses this pattern
to legitimately invoke a destructor immediately (or the statement is
at the end of a scope anyway). To reduce the number we ignore this
pattern in macros (this is heavily used by gtest) and ignore objects
with no user-defined destructor.
Reviewers: alexfh, djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4615
llvm-svn: 213647
This looks for swapped arguments by looking at implicit conversions of arguments
void Foo(int, double);
Foo(1.0, 3); // Most likely a bug
llvm-svn: 212942
The goal is to find code like the example below, which is likely a typo
where someone meant to write "if (*b)".
bool *b = SomeFunction();
if (b) {
// b never dereferenced
}
This checker naturally has a relatively high false positive rate so it
applies some heuristics to avoid cases where the pointer is checked for
nullptr before being written.
Differential Revision: http://reviews.llvm.org/D4458
llvm-svn: 212797
This breaks with MSVC.
With IsLateTemplateParsed, FunctionDecl::doesThisDeclarationHaveABody() returns true regardless of Body.
This reinstates what was fixed in r208985.
llvm-svn: 209896
Summary:
These calls are part of the implementation of the smart pointer itself
and chaning it is likely to be wrong.
Example:
T& operator*() const { return *get(); }
Reviewers: djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3540
llvm-svn: 207525
Summary:
Extend the check to detect patterns like 'ptr.get() == nullptr'
It detects == and != when any argument is a ptr.get() and the other is a
nullptr.
Only supports standard smart pointer types std::unique_ptr and std::shared_ptr.
Does not support the case 'ptr.get() == other.get()' yet.
Reviewers: djasper
CC: cfe-commits, alexfh
Differential Revision: http://llvm-reviews.chandlerc.com/D3294
llvm-svn: 205854
This checks that parameters named in comments that appear before arguments in
function and constructor calls match the parameter name used in the callee's
declaration. For example:
void f(int x, int y);
void g() {
f(/*y=*/0, /*z=*/0);
}
contains two violations of the policy, as the names 'x' and 'y' used in the
declaration do not match names 'y' and 'z' used at the call site.
I think there is significant value in being able to check/enforce this policy
as a way of guarding against accidental API misuse and silent breakages
caused by API changes.
Although this pattern appears somewhat frequently in the LLVM codebase,
this policy is not prescribed by the LLVM coding standards at the moment,
so it lives under 'misc'.
Differential Revision: http://llvm-reviews.chandlerc.com/D2914
llvm-svn: 204113
Alexander Kornienko