Before the patch calling clang-tidy with -header-filter=.* -system-headers would
result in a few hundred useless warnings:
warning: macro '_GNU_SOURCE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '_LP64' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQUIRE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQ_REL' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_CONSUME' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELAXED' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELEASE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_SEQ_CST' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__BIGGEST_ALIGNMENT__' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
... and so on
llvm-svn: 358621
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Removed the uses of the allOf() matcher inside node matchers that are implicit
allOf(). Replaced uses of allOf() with the explicit node matcher where it makes
matchers more readable. Replace anyOf(hasName(), hasName(), ...) with the more
efficient and readable hasAnyName().
llvm-svn: 347520
Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=39224 | PR39224 ]]
As discussed, we can't always do the transform automatically due to that array-to-pointer decay of C array.
In order to detect whether we can do said transform, we'd need to be able to see all usages of said array,
which is, i would say, rather impossible if e.g. it is in the header.
Thus right now no fixit exists.
Exceptions: `extern "C"` code.
References:
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es27-use-stdarray-or-stack_array-for-arrays-on-the-stack | CPPCG ES.27: Use std::array or stack_array for arrays on the stack ]]
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slcon1-prefer-using-stl-array-or-vector-instead-of-a-c-array | CPPCG SL.con.1: Prefer using STL array or vector instead of a C array ]]
* HICPP `4.1.1 Ensure that a function argument does not undergo an array-to-pointer conversion`
* MISRA `5-2-12 An identifier with array type passed as a function argument shall not decay to a pointer`
Reviewers: aaron.ballman, JonasToth, alexfh, hokein, xazax.hun
Reviewed By: JonasToth
Subscribers: Eugene.Zelenko, mgorny, rnkovacs, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D53771
llvm-svn: 346835
Summary:
The fix to the issue that `const char* p = ("foo")` is diagnosed as decay
is to ignored the ParenCast.
Resolves PR39583
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D54281
llvm-svn: 346555
Summary:
The macro may not have location (or more generally, the location may not exist),
e.g. if it originates from compiler's command-line.
The check complains on all the macros, even those without the location info.
Which means, it only says it does not like it. What is 'it'? I have no idea.
If we don't print the name, then there is no way to deal with that situation.
And in general, not printing name here forces the user to try to understand,
given, the macro definition location, what is the macro name?
This isn't fun.
Also, ignores-by-default the macros originating from command-line,
with an option to not ignore those.
I suspect some more issues may crop up later.
Reviewers: JonasToth, aaron.ballman, hokein, xazax.hun, alexfh
Reviewed By: JonasToth, aaron.ballman
Subscribers: nemanjai, kbarton, rnkovacs, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D53817
llvm-svn: 345610
Summary:
This patch is a small refactoring necessary for
'readability-isolate-declaration' and does not introduce functional changes.
It allows to use the utility functions without a full `ASTContext` and requires only the `SourceManager` and the `LangOpts`.
Reviewers: alexfh, aaron.ballman, hokein
Reviewed By: alexfh
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D52684
llvm-svn: 343850
Summary:
The cppcoreguidelines-pro-bounds-pointer-arithmetic warns on all occassion where
pointer arithmetic is used, but does not check values where the pointer types
is deduced via `auto`. This patch adjusts this behaviour and solved
PR36489.
I accidentally commited a wrong patch, this Differential is meant to have a
correct revision description and code attached to it.
Because the patch was accepted by aaron.ballman already, i will just commit
it.
See https://reviews.llvm.org/D48717 for the old differntial (contains wrong
code from the mixup)
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D49682
llvm-svn: 337716
Summary:
Checks for narrowing conversions, e.g.
int i = 0;
i += 0.1;
This has what some might consider false positives for:
i += ceil(d);
Reviewers: alexfh, hokein
Subscribers: srhines, nemanjai, mgorny, JDevlieghere, xazax.hun, kbarton
Differential Revision: https://reviews.llvm.org/D38455
llvm-svn: 333066
Summary:
C++2a allows bitfields to have default member initializers.
Add support for this to clang-tidy's cppcoreguidelines-pro-type-member-init check.
Reviewers: aaron.ballman, alexfh
Reviewed By: aaron.ballman
Subscribers: klimek, nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D42426
llvm-svn: 323227
The usage of `goto` is discourage in C++ since forever. This check implements
a warning for every `goto`. Even though there are (rare) valid use cases for
`goto`, better high level constructs should be used.
`goto` is used sometimes in C programs to free resources at the end of
functions in the case of errors. This pattern is better implemented with
RAII in C++.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, jbcoe, Eugene.Zelenko, klimek, nemanjai, mgorny, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D41815
llvm-svn: 322626
Summary:
This patch introduces support for legacy C-style resource functions that must obey
the 'owner<>' semantics.
- added legacy creators like malloc,fopen,...
- added legacy consumers like free,fclose,...
This helps codes that mostly benefit from owner:
Legacy, C-Style code that isn't feasable to port directly to RAII but needs a step in between
to identify actual resource management and just using the resources.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: nemanjai, JDevlieghere, xazax.hun, kbarton
Differential Revision: https://reviews.llvm.org/D38396
llvm-svn: 316092
This patch introduces a note for variable declaration that are later deleted.
Adds FIXME notes for possible automatic type-rewriting positions as well.
Reviewed by aaron.ballman
Differential: https://reviews.llvm.org/D38411
llvm-svn: 314913
This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Codereview in D36354
llvm-svn: 313067
This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Please give your comments :)
llvm-svn: 313043
ADL as reasonable extension points.
All of this would be cleaner if this code followed the more usual LLVM
convention of not having deeply nested namespaces inside of .cpp files
and instead having a `using namespace ...;` at the top. Then the static
function would be in the global namespace and easily referred to as
`::join`. Instead we have to write a fairly contrived qualified name.
I figure the authors can clean this up with a less ambiguous name, using
the newly provided LLVM `join` function, or any other solution, but this
at least fixes the build.
llvm-svn: 298434
Summary:
Hello everybody,
this is an incremental patch for the NoMalloc-Checker I wrote. It allows to configure the memory-management functions, that are checked,
This might be helpful for a code base with custom functions in use, or non-standard functionality, like posix_memalign.
Reviewers: aaron.ballman, hokein, alexfh
Reviewed By: aaron.ballman, alexfh
Subscribers: sbenza, nemanjai, JDevlieghere
Tags: #clang-tools-extra
Patch by Jonas Toth!
Differential Revision: https://reviews.llvm.org/D28239
llvm-svn: 296734
Summary:
This checker flags the use of C-style memory management functionality and notes about modern alternatives.
In an earlier revision it tried to autofix some kind of patterns, but that was a bad idea. Since memory management can be so widespread in a program, manual updating is most likely necessary.
Maybe for special cases, there could be later additions to this basic checker.
This is the first checker I wrote and I never did something with clang (only compiling programs). So whenever I missed conventions or did plain retarded stuff, feel free to point it out! I am willing to fix them and write a better checker.
I hope the patch does work, I never did this either. On a testapply in my repository it did, but I am pretty unconfident in my patching skills :)
Reviewers: aaron.ballman, hokein, alexfh, malcolm.parsons
Subscribers: cfe-commits, JDevlieghere, nemanjai, Eugene.Zelenko, Prazek, mgorny, modocache
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D26167
Patch by Jonas Toth!
llvm-svn: 289546
Matthias Gehre