Summary:
Depends on D23204.
This is intended to be submitted immediately after D23204 lands.
Reviewers: jdennett, alexfh
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D23543
llvm-svn: 278934
...
This check verifies if a buffer passed to an MPI (Message Passing Interface)
function is sufficiently dereferenced. Buffers should be passed as a single
pointer or array. As MPI function signatures specify void * for their buffer
types, insufficiently dereferenced buffers can be passed, like for example
as double pointers or multidimensional arrays, without a compiler warning
emitted.
Instructions on how to apply the check can be found at:
https://github.com/0ax1/MPI-Checker/tree/master/examples
Reviewers: Haojian Wu
Differential revision: https://reviews.llvm.org/D22729
llvm-svn: 278553
The include order check would get notified of all include
directives in a depth-first manner. This created the
possibility of an include directive from a header file
interfering with the sort order of a set of two distinct
blocks from the top level cpp file, if that include directive
was on just the right line.
With this patch we bucket the include directives by the file
in which they appear in and process one bucket at a time,
so that directives from different files do not get mixed
together into the same list.
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D23434
llvm-svn: 278546
`readability-else-after-return` only warns about `return` calls, but LLVM Coding
Standars stat that `throw`, `continue`, `goto`, etc after `return` calls are
bad, too.
Reviwers: alexfh, aaron.ballman
Differential Revision: https://reviews.llvm.org/D23265
llvm-svn: 278257
This patch introduces a minor list of changes as proposed by Richard Smith in
the mailing list.
See original comments with an impact on the future check state below:
[comments.begin
> + {"complex.h", "ccomplex"},
It'd be better to convert this one to <complex>, or leave it alone.
<ccomplex> is an unnecessary wart.
(The contents of C++11's <complex.h> / <ccomplex> / <complex> (all of
which are identical) aren't comparable to C99's <complex.h>, so if
this was C++98 code using the C99 header, the code will be broken with
or without this transformation.)
> + {"iso646.h", "ciso646"},
Just delete #includes of this one. <ciso646> does nothing.
> + {"stdalign.h", "cstdalign"},
> + {"stdbool.h", "cstdbool"},
We should just delete these two includes. These headers do nothing in C++.
comments.end]
Reviewers: alexfh, aaron.ballman
Differential Revision: https://reviews.llvm.org/D17990
llvm-svn: 278254
Summary:
tooling::Replacements only holds replacements for a single file, so
this patch makes Fix a map from file paths to tooling::Replacements so that it
can be applied on multiple files.
Reviewers: hokein, alexfh
Subscribers: Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23257
llvm-svn: 278101
This differs from the previous version by being more careful about template
instantiation/specialization in order to prevent errors when building with
clang -Werror. Specifically:
* begin is not defined in the template and is instead instantiated when Head
is. I think the warning when we don't do that is wrong (PR28815) but for now
at least do it this way to avoid the warning.
* Instead of performing template specializations in LLVM_INSTANTIATE_REGISTRY
instead provide a template definition then do explicit instantiation. No
compiler I've tried has problems with doing it the other way, but strictly
speaking it's not permitted by the C++ standard so better safe than sorry.
Original commit message:
Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.
This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.
llvm-svn: 277806
Summary:
The misc-argument-comment check now ignores leading and trailing underscores and
case. The new `StrictMode` local/global option can be used to switch back to
strict checking.
Add getLocalOrGlobal version for integral types, minor cleanups.
Reviewers: hokein, aaron.ballman
Subscribers: aaron.ballman, Prazek, cfe-commits
Differential Revision: https://reviews.llvm.org/D23135
llvm-svn: 277729
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/clang-tidy/mpi/TypeMismatchCheck.cpp:172:12: warning: parameter 'Complex' not found in the function declaration [-Wdocumentation]
/home/llvmbb/llvm-build-dir/clang-x86_64-debian-fast/llvm.src/tools/clang/tools/extra/clang-tidy/mpi/TypeMismatchCheck.cpp:206:12: warning: parameter 'Complex' not fo
llvm-svn: 277578
Summary:
This patch is fixing the build bot broken for a missing dependency.
The missing dependency is breaking "shared" build.
```
./mpi/TypeMismatchCheck.cpp:
#include "clang/StaticAnalyzer/Checkers/MPIFunctionClassifier.h"
```
I'm not a fan of that fix. It's brining a strange dependency.
Reviewers: alexfh
Subscribers: llvm-commits, chrisha
Differential Revision: https://reviews.llvm.org/D23093
llvm-svn: 277539
Summary:
Use a set rather than a vector of defined special member functions so
that multiple declarations of the same function are only counted once.
Move some private static member functions into the cpp file.
Run clang-format on header.
Reviewers: ericLemanissier, Prazek, aaron.ballman
Subscribers: Prazek, cfe-commits, nemanjai
Projects: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D23008
llvm-svn: 277523
This check verifies if buffer type and MPI (Message Passing Interface)
datatype pairs match. All MPI datatypes defined by the MPI standard (3.1)
are verified by this check. User defined typedefs, custom MPI datatypes and
null pointer constants are skipped, in the course of verification.
Instructions on how to apply the check can be found at:
https://github.com/0ax1/MPI-Checker/tree/master/examples
Patch by Alexander Droste!
Differential revision: https://reviews.llvm.org/D21962
llvm-svn: 277516
function call expression.
Summary:
The check doesn't mark the template argument as used when the template
argument is a template.
Reviewers: djasper, alexfh
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D22803
llvm-svn: 277444
Summary:
D22566 will change RecursiveASTVisitor so that it descends into the initialization expressions for lambda captures.
modernize-loop-convert needs to be prepared for this so that it does not interpret these initialization expressions as invalid uses of the loop variable. The change has no ill effects without D22566 in place, i.e. the change does not depend on D22566.
Reviewers: klimek
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D22903
llvm-svn: 277339
This version has two fixes compared to the original:
* In Registry.h the template static members are instantiated before they are
used, as clang gives an error if you do it the other way around.
* The use of the Registry template in clang-tidy is updated in the same way as
has been done everywhere else.
Original commit message:
Currently the Registry class contains the vestiges of a previous attempt to
allow plugins to be used on Windows without using BUILD_SHARED_LIBS, where a
plugin would have its own copy of a registry and export it to be imported by
the tool that's loading the plugin. This only works if the plugin is entirely
self-contained with the only interface between the plugin and tool being the
registry, and in particular this conflicts with how IR pass plugins work.
This patch changes things so that instead the add_node function of the registry
is exported by the tool and then imported by the plugin, which solves this
problem and also means that instead of every plugin having to export every
registry they use instead LLVM only has to export the add_node functions. This
allows plugins that use a registry to work on Windows if
LLVM_EXPORT_SYMBOLS_FOR_PLUGINS is used.
llvm-svn: 276973
Summary:
This check verifies if buffer type and MPI (Message Passing Interface)
datatype pairs match. All MPI datatypes defined by the MPI standard (3.1)
are verified by this check. User defined typedefs, custom MPI datatypes and
null pointer constants are skipped, in the course of verification.
Instructions on how to apply the check can be found at: https://github.com/0ax1/MPI-Checker/tree/master/examples
Reviewers: alexfh
Subscribers: cfe-commits
Projects: #clang-tools-extra
Patch by Alexander Droste!
Differential Revision: https://reviews.llvm.org/D21962
llvm-svn: 276640
Summary:
Previoly, the added test failed with the fillowing fixit:
char v[5];
- for(size_t i = 0; i < 5; ++i)
+ for(char value : v)
{
- unsigned char value = v[i];
if (value > 127)
i.e. the variable 'value' changes from unsigned char to signed char. And
thus the following 'if' does not work anymore.
With this commit, the fixit is changed to:
char v[5];
- for(size_t i = 0; i < 5; ++i)
+ for(unsigned char value : v)
{
- unsigned char value = v[i];
if (value > 127)
Reviewers: alexfh, klimek
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D22069
llvm-svn: 276111
Summary:
When the expression is value dependent,
isIntegerConstantExpr() crashes in C++03 mode with
../tools/clang/lib/AST/ExprConstant.cpp:9330: (anonymous namespace)::ICEDiag CheckICE(const clang::Expr *, const clang::ASTContext &):
Assertion `!E->isValueDependent() && "Should not see value dependent exprs!"' failed.
In C++11 mode, that assert does not trigger.
This commit works around this in the check. We don't check
value-dependent indices and instead check their specialization.
Reviewers: alexfh, aaron.ballman
Subscribers: nemanjai, cfe-commits
Differential Revision: http://reviews.llvm.org/D22190
llvm-svn: 275461
Summary:
Although there is no guarantee of getOptions/getRawOptions receiving an
absolute path, we try to make it if possible. So FileOptionProvider subclasses
don't have to convert the path to an absolute path.
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D22154
llvm-svn: 275051
Summary:
Previously, the added test cases crashed because the passed a null Decl
to addUsage().
Reviewers: alexfh
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D22188
llvm-svn: 274985
Currently, to be able to process a source file including e.g. stddef.h with
clang-tidy, one has to build both clang-tidy and the clang-headers target.
Since stddef.h is needed for virtually any source file, let clang-tidy depend
on clang-headers, so that it Just Works after it has been built.
http://reviews.llvm.org/D22046
llvm-svn: 274751
Summary: This patch is adding support to recognize more complex redundant expressions.
Reviewers: alexfh
Subscribers: aaron.ballman, cfe-commits, chrisha
Differential Revision: http://reviews.llvm.org/D21392
llvm-svn: 274731
Summary:
Make check more useful in the following two cases:
The parameter is passed by non-const value, has a non-deleted move constructor and is only referenced once in the function as argument to the type's copy constructor.
The parameter is passed by non-const value, has a non-deleted move assignment operator and is only referenced once in the function as argument of the the type's copy assignment operator.
In this case suggest a fix to move the parameter which avoids the unnecessary copy and is closest to what the user might have intended.
Reviewers: alexfh, sbenza
Subscribers: cfe-commits, Prazek
Differential Revision: http://reviews.llvm.org/D20277
llvm-svn: 274380
We match on the generated FunctionDecl of the lambda and try to fix it.
This causes a crash.
The right behavior is to ignore lambdas, because they are a definition.
llvm-svn: 274019
Kirill Bobyrev