Summary:
Also displays a hint to use -header-filter='.*' in case any warnings
are in non-user code. This will help discoverability of this option.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3621
llvm-svn: 208174
defined in a macro.
Summary:
We shouldn't suggest replacements in macros anyway, as we can't see all
usages of the macro and ensure the replacement is safe for all of them.
Reviewers: klimek
Reviewed By: klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3611
llvm-svn: 207987
Summary:
Add clang-tidy -header-filter option to specify from which headers we
want diagnostics to be printed. By default we don't print diagnostics from
headers. We always print diagnostics from the main file of each translation
unit.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D3590
llvm-svn: 207970
Summary:
The Google C++ Style Guide doesn't require copy constructors to be
declared explicit, but some people do this by mistake. Make this check detect
and fix such cases.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3541
llvm-svn: 207531
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:
Add new 'let' command to bind arbitrary values into constants.
These constants can then be used in the matcher expressions.
Reviewers: pcc
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3383
llvm-svn: 206984
Summary:
Inject unique_ptr/shared_ptr into the test instead of using <memory>
Libraries might not be present on tests.
This fixes the break introduces at rL205854.
Reviewers: klimek
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D3330
llvm-svn: 205913
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
Also make tests slightly less dependent on default flags. Once we have
implemented configuration file support, we might want to store the
clang-tidy configuration for the tests there.
llvm-svn: 205408
The goal is to be able to run clang-tidy on LLVM files without further
configuration for now. Once llvm.org/PR19306 is addressed, we can add a
configuration file instead and choose other defaults.
llvm-svn: 205407
Summary:
When clang-apply-replacements wasn't in the PATH or sitting next to
clang-modernize, findClangApplyReplacements() was finding the wrong path
(pointing to clang-modernize instead of nothing).
See the related PR at http://llvm.org/bugs/show_bug.cgi?id=18421
Reviewers: klimek
CC: silvas, cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3217
llvm-svn: 205136
Summary:
This patch implements filtering of clang-tidy diagnostic messages by
the check name, so that "clang-tidy -checks=^llvm-" won't output any clang
warnings, for example. This is also helpful to run specific static-analyzer
checks: static analyzer always needs core checks to be enabled, but the user may
be interested only in the checks he asked for.
This patch also exposes warning option names for built-in diagnostics. We need
to have a namespace for these names to avoid collisions and to allow convenient
filtering, so I prefix them with "-W". I'm not sure it's the best thing to do,
and maybe "W" or "clang-diagnostic-" or something like this would be better.
Reviewers: klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3121
llvm-svn: 204321
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
Summary:
This is immediately useful for generating macro expansion notes, and
may be useful for other things later on.
Reviewers: klimek, djasper
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2950
llvm-svn: 203457
Summary: Peter, I guess, this can help you in testing your check.
Reviewers: djasper, pcc, klimek
Reviewed By: klimek
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2989
llvm-svn: 203451
This removes all references to OwningPtr, which should be fairly
undisruptive to out-of-tree projects since they are unlikely to use
clang-tools-extra as a library instead of a set of tools.
llvm-svn: 203382
Alexander Kornienko