`LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES` is not completely
compatible with `export_executable_symbols` as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
`llvm_add_exectuable` so the link flag can be determined directly
without calling `export_executable_symbols_*` later.
Adds a description parameter that automatically fills in the Release
notes and first line of the checks documentation. If omitted the usually
FIXME markers are left in their place.
Crash seems to be caused by the check function not handling inline
namespaces correctly for some instances. Changed how the Replacer is got
from the MatchResult now which should alleviate any potential issues
Fixes#100406
... so that downstream checks can override behaviour to do additional
processing.
Refactor the rest of the logic to `handleConstRefFix` (which is also
`virtual`).
This is otherwise and NFC.
This is similar to https://github.com/llvm/llvm-project/pull/73921 but
for `performance-unnecessary-value-param`.
Function areStatementsIdentical had an early exit
when classes of stmt does not match. That if were
added to speed up checking and do not calculate
hash id of both objects if they are not the same
type. Due to some bug, wrong pointer were used
and this resulted with comparing self to self.
This patch fixes this issue.
Fix issues in list.rst, addapt add_new_check.py to new
format of that file, and run gen-static-analyzer-docs.py
to generate missing documentation for clang-analyzer.
As in title, code which checks eligibility of exceptions with pointer
types to be handled by exception handler of type `void *` disallowed
this case. It was working like this:
```c++
if (isStandardPointerConvertible(ExceptionCanTy, HandlerCanTy) &&
isUnambiguousPublicBaseClass(
ExceptionCanTy->getTypePtr()->getPointeeType().getTypePtr(),
HandlerCanTy->getTypePtr()->getPointeeType().getTypePtr())) {
```
but in `isUnambiguousPublicBaseClass` there was code which looked for
definitions:
```c++
bool isUnambiguousPublicBaseClass(const Type *DerivedType,
const Type *BaseType) {
const auto *DerivedClass =
DerivedType->getCanonicalTypeUnqualified()->getAsCXXRecordDecl();
const auto *BaseClass =
BaseType->getCanonicalTypeUnqualified()->getAsCXXRecordDecl();
if (!DerivedClass || !BaseClass)
return false;
```
This code disallowed usage of `void *` type which was already correctly
detected in `isStandardPointerConvertible`.
AFAIK this seems like misinterpretation of specification:
> 14.4 Handling an exception
> a standard [pointer conversion](https://eel.is/c++draft/conv.ptr) not
involving conversions to pointers to private or protected or ambiguous
classes
(https://eel.is/c++draft/except.handle#3.3.1)
and
> 7.3.12 Pointer conversions
> ... If B is an inaccessible
([[class.access]](https://eel.is/c++draft/class.access)) or ambiguous
([[class.member.lookup]](https://eel.is/c++draft/class.member.lookup))
base class of D, a program that necessitates this conversion is
ill-formed[.](https://eel.is/c++draft/conv.ptr#3.sentence-2) ...
(https://eel.is/c++draft/conv.ptr#3)
14.4 is carving out private, protected, and ambiguous base classes, but
they are already carved out in 7.3.12 and implemented in
`isStandardPointerConvertible`
---------
Co-authored-by: Piotr Zegar <me@piotrzegar.pl>
The regular expressions match functions that aren't anchored in the
global namespace. For example `::remove` matches any object with a
`removeXyz` method. This change is to remove these false positives
[There is
work](https://discourse.llvm.org/t/rfc-upgrading-llvms-minimum-required-python-version/67571)
to make Python 3.8 the minimum Python version for LLVM.
I edited this script because I wanted some indicator of progress while
going through files.
It now outputs `[XX/YYY]` with the number of processed and total files
after each completion.
The current version of this script is compatible downto Python 3.6 (this
is PyYAML's minimum version).
It would probably work with older Python 3 versions with an older PyYAML
or when YAML is disabled.
With the updates here, it is compatible downto Python 3.7. Python 3.7
was released June 2018.
https://github.com/llvm/llvm-project/pull/89302 is also touching this
file, I don't mind rebasing on top of that work if needed.
### Summary
- Add type annotations.
- Replace `threading` + `queue` with `asyncio`.
- **Add indicator of processed files over total files**. This is what I
set out to do initially.
- Only print the filename after completion, not the entire Clang-Tidy
invocation command. I find this neater but the behavior can easily be
restored.
The regular expressions match functions that aren't anchored in the
global namespace. For example `::connect` matches `QObject::connect`
This change is to remove these false positives
When fixing #92896 in 0e62d5cf55479981da5e05e406bbca4afb3cdc4f (#94104)
I failed to spot that I'd broken converting from fmt::printf,
fmt::fprintf and fmt::sprintf in these checks since the format parameter
of those functions is not a simple character pointer.
The first part of the previous fix to avoid the assert and instead
produce an error message was sufficient. It was only the second part
that required the format parameter of the called function to be a simple
character pointer that was problematic. Let's remove that second part
and add the now-expected error messages to the lit tests along with
fixing the prototype for the fmt functions to more accurately reflect
the ones used by the fmt library so they are actually useful.
Fixes#92896
These algorithms take 3 iterators for the range and we are only
interested in the first and last iterator argument. The ranges versions
of these take a range and an iterator(defined to be inside the range) so
the transformation is pretty similar `algo(I.begin, other, I.end,...)`
-> `ranges::algo(I, other,...)`
Add an option to the
`bugprone-implicit-widening-of-multiplication-result` clang-tidy checker
to suppress warnings when the expression is made up of all compile-time
constants (literals, `constexpr` values or results, etc.) and the result
of the multiplication is guaranteed to fit in both the source and
destination types.
This currently only works for signed integer types:
* For unsigned integers, the well-defined rollover behavior on overflow
prevents the checker from detecting that the expression does not
actually fit in the source expr type, and would produce false negatives.
I have a somewhat-hacky stab at addressing this I'd like to submit as a
follow-on PR
* For floating-point types, there's probably a little additional work to
be done to `Expr` to calculate the result at compile time
Even still, this seems like a helpful addition just for signed types,
and additional types can be added.
Clang-Tidy unnecessary-value-param value param will be triggered for
templated functions if at least one instantiontion with expensive to
copy type is present in translation unit.
It is relatively common mistake to write lambda functions with auto
arguments for expensive to copy types.
Add `UseReversePipe` option to (boost|modernize)-use-ranges checks. This
controls whether to create a reverse view using function syntax
(`reverse(Range)`) or pipe syntax (`Range | reverse`)
Currently, `NamespaceDecl` has a member `AnonOrFirstNamespaceAndFlags`
which stores a few pieces of data:
- a bit indicating whether the namespace was declared `inline`, and
- a bit indicating whether the namespace was declared as a
_nested-namespace-definition_, and
- a pointer a `NamespaceDecl` that either stores:
- a pointer to the first declaration of that namespace if the
declaration is no the first declaration, or
- a pointer to the unnamed namespace that inhabits the namespace
otherwise.
`Redeclarable` already stores a pointer to the first declaration of an
entity, so it's unnecessary to store this in `NamespaceDecl`.
`DeclContext` has 8 bytes in which various bitfields can be stored for a
declaration, so it's not necessary to store these in `NamespaceDecl`
either. We only need to store a pointer to the unnamed namespace that
inhabits the first declaration of a namespace. This patch moves the two
bits currently stored in `NamespaceDecl` to `DeclContext`, and only
stores a pointer to the unnamed namespace that inhabits a namespace in
the first declaration of that namespace. Since `getOriginalNamespace`
always returns the same `NamespaceDecl` as `getFirstDecl`, this function
is removed to avoid confusion.
This patch updates the clang-tidy checks for llvm-libc to ensure that
the namespace macro used to declare the libc namespace is updated from
LIBC_NAMESPACE to LIBC_NAMESPACE_DECL which by default has hidden
visibility.
Co-authored-by: Prabhu Rajesakeran <prabhukr@google.com>
before this change, we use an output parameter so
`UseAfterMoveFinder::find()` can return the found `UseAfterMove`, and
addition to it, `UseAfterMoveFinder::find()` return a bool, so we can
tell if a use-after-free is identified. this arrangement could be
confusing when one needs to understand when the each member variable of
the returned `UseAfterMove` instance is initialized.
in this change, we return an `std::optional<UseAfterMove>` instead of a
bool, so that it's more obvious on when/where the returned
`UseAfterMove` is initialized.
this change is a cleanup. so it does not change the behavior of this
check.
Signed-off-by: Kefu Chai <kefu.chai@scylladb.com>
This eliminates false positives in bugprone-use-after-move where a
variable
is used in the callee and moved from in the arguments.
We introduce one special case: If the callee is a MemberExpr with a
DeclRefExpr as its base, we consider it to be sequenced after the
arguments. This is because the variable referenced in the base will only
actually be accessed when the call happens, i.e. once all of the
arguments have been evaluated. This has no basis in the C++ standard,
but it reflects actual behavior that is relevant to a use-after-move
scenario:
```c++
a.bar(consumeA(std::move(a));
```
In this example, we end up accessing a after it has been moved from,
even though nominally the callee a.bar is evaluated before the argument
consumeA(std::move(a)).
Treating this scenario correctly has required rewriting the logic in
bugprone-use-after-move that governs whether the use happens in a later
loop iteration than the move. This was previously based on an unsound
heuristic (does the use come lexically before the move?); we now use a
more rigourous criterion based on reachability in the CFG.
Fixes#57758Fixes#59612
Co-authored-by: martinboehme <mboehme@google.com>
Add an option to ignore warnings for cppcoreguidelines
avoid-non-const-global-variables.
Understandably, the core guidelines discourage non const global
variables, even at the TU level (see
https://github.com/isocpp/CppCoreGuidelines/issues/2195). However,
having a small TU with an interface that uses a non const variable from
an anonymous namespace can be a valid choice.
This adds an option that disables the warning just for anonymous
namespaces, i.e. at the file level. The default is still to show a
warning, just as before.
When clang-tidy get an empty checks, it will throw "no checks enabled"
error and exit with non-zero return value.
It make clang-tidy's wrapper program confused when in big project some
files don't want to be checked and use `-checks=-*` to disable all
checks.
---------
Co-authored-by: Danny Mösch <danny.moesch@icloud.com>
This commit reimplements the functionality of the Clang Static Analyzer
checker `alpha.core.SizeofPointer` within clang-tidy by adding a new
(off-by-default) option to bugprone-sizeof-expression which activates
reporting all the `sizeof(ptr)` expressions (where ptr is an expression
that produces a pointer).
The main motivation for this change is that `alpha.core.SizeofPointer`
was an AST-based checker, which did not rely on the path sensitive
capabilities of the Static Analyzer, so there was no reason to keep it
in the Static Analyzer instead of the more lightweight clang-tidy.
After this commit I'm planning to create a separate commit that deletes
`alpha.core.SizeofPointer` from Clang Static Analyzer.
It was natural to place this moved logic in bugprone-sizeof-expression,
because that check already provided several heuristics that reported
various especially suspicious classes of `sizeof(ptr)` expressions.
The new mode `WarnOnSizeOfPointer` is off-by-default, so it won't
surprise the existing users; but it can provide a more through coverage
for the vulnerability CWE-467 ("Use of sizeof() on a Pointer Type") than
the existing partial heuristics.
Previously this checker had an exception that the RHS of a
`sizeof(array) / sizeof(array[0])` expression is not reported; I
generalized this to an exception that the check doesn't report
`sizeof(expr[0])` and `sizeof(*expr)`. This idea is taken from the
Static Analyzer checker `alpha.core.SizeofPointer` (which had an
exception for `*expr`), but analysis of open source projects confirmed
that this indeed eliminates lots of unwanted results.
Note that the suppression of `sizeof(expr[0])` and `sizeof(*expr)`
reports also affects the "old" mode `WarnOnSizeOfPointerToAggregate`
which is enabled by default.
This commit also replaces the old message "suspicious usage of
'sizeof(A*)'; pointer to aggregate" with two more concrete messages; but
I feel that this tidy check would deserve a through cleanup of all the
diagnostic messages that it can produce. (I added a FIXME to mark one
outright misleading message.)
…and operators that have non-const overloads.
This allows `unnecessary-copy-initialization` to warn on more cases.
The common case is a class with a a set of const/non-sconst overloads
(e.g. std::vector::operator[]).
```
void F() {
std::vector<Expensive> v;
// ...
const Expensive e = v[i];
}
```
