```cpp
struct Base {
int m;
};
template <class T>
struct Derived : Base {
Derived() { m = 0; }
};
```
would previously generate the following output:
```
<source>:7:15: warning: 'm' should be initialized in a member initializer of the constructor [cppcoreguidelines-prefer-member-initializer]
7 | Derived() { m = 0; }
| ^~~~~~
| : m(0)
```
This patch fixes this false positive.
Note that before this patch the checker won't give false positive for
```cpp
struct Derived : Base {
Derived() { m = 0; }
};
```
and the constructor's AST is
```
`-CXXConstructorDecl 0x557df03d1fb0 <line:7:3, col:22> col:3 Derived 'void ()' implicit-inline
|-CXXCtorInitializer 'Base'
| `-CXXConstructExpr 0x557df03d2748 <col:3> 'Base' 'void () noexcept'
`-CompoundStmt 0x557df03d2898 <col:13, col:22>
`-BinaryOperator 0x557df03d2878 <col:15, col:19> 'int' lvalue '='
|-MemberExpr 0x557df03d2828 <col:15> 'int' lvalue ->m 0x557df03d1c40
| `-ImplicitCastExpr 0x557df03d2808 <col:15> 'Base *' <UncheckedDerivedToBase (Base)>
| `-CXXThisExpr 0x557df03d27f8 <col:15> 'Derived *' implicit this
`-IntegerLiteral 0x557df03d2858 <col:19> 'int' 0
```
so `isAssignmentToMemberOf` would return empty due to
f0967fca04/clang-tools-extra/clang-tidy/cppcoreguidelines/PreferMemberInitializerCheck.cpp (L118-L119)Fixes#104400
This is a major change on how we represent nested name qualifications in
the AST.
* The nested name specifier itself and how it's stored is changed. The
prefixes for types are handled within the type hierarchy, which makes
canonicalization for them super cheap, no memory allocation required.
Also translating a type into nested name specifier form becomes a no-op.
An identifier is stored as a DependentNameType. The nested name
specifier gains a lightweight handle class, to be used instead of
passing around pointers, which is similar to what is implemented for
TemplateName. There is still one free bit available, and this handle can
be used within a PointerUnion and PointerIntPair, which should keep
bit-packing aficionados happy.
* The ElaboratedType node is removed, all type nodes in which it could
previously apply to can now store the elaborated keyword and name
qualifier, tail allocating when present.
* TagTypes can now point to the exact declaration found when producing
these, as opposed to the previous situation of there only existing one
TagType per entity. This increases the amount of type sugar retained,
and can have several applications, for example in tracking module
ownership, and other tools which care about source file origins, such as
IWYU. These TagTypes are lazily allocated, in order to limit the
increase in AST size.
This patch offers a great performance benefit.
It greatly improves compilation time for
[stdexec](https://github.com/NVIDIA/stdexec). For one datapoint, for
`test_on2.cpp` in that project, which is the slowest compiling test,
this patch improves `-c` compilation time by about 7.2%, with the
`-fsyntax-only` improvement being at ~12%.
This has great results on compile-time-tracker as well:
This patch also further enables other optimziations in the future, and
will reduce the performance impact of template specialization resugaring
when that lands.
It has some other miscelaneous drive-by fixes.
About the review: Yes the patch is huge, sorry about that. Part of the
reason is that I started by the nested name specifier part, before the
ElaboratedType part, but that had a huge performance downside, as
ElaboratedType is a big performance hog. I didn't have the steam to go
back and change the patch after the fact.
There is also a lot of internal API changes, and it made sense to remove
ElaboratedType in one go, versus removing it from one type at a time, as
that would present much more churn to the users. Also, the nested name
specifier having a different API avoids missing changes related to how
prefixes work now, which could make existing code compile but not work.
How to review: The important changes are all in
`clang/include/clang/AST` and `clang/lib/AST`, with also important
changes in `clang/lib/Sema/TreeTransform.h`.
The rest and bulk of the changes are mostly consequences of the changes
in API.
PS: TagType::getDecl is renamed to `getOriginalDecl` in this patch, just
for easier to rebasing. I plan to rename it back after this lands.
Fixes#136624
Fixes https://github.com/llvm/llvm-project/issues/43179
Fixes https://github.com/llvm/llvm-project/issues/68670
Fixes https://github.com/llvm/llvm-project/issues/92757
This check already understands how `constexpr` makes initialization
order problems impossible, and C++20's `constinit` provides the exact
same guarantees.
Added `.clang-tidy` config as discussed in
[RFC](https://discourse.llvm.org/t/rfc-create-hardened-clang-tidy-config-for-clang-tidy-directory/87247).
Added `bugprone`, `readability`, `modernize`, `performance` checks that
didn't create many warnings.
Fixed minor warnings to make `/clang-tidy` directory complaint with
`clang-tidy-20`.
Disabled checks will be enabled in future PRs after fixing their
warnings.
Some of these are even global mutable state — probably not what was
intended!
```cpp
static const char *AnalyzerCheckNamePrefix = "clang-analyzer-";
```
Fixed false negatives with type aliases in
`cppcoreguidlines-pro-bounds-pointer-arithmetic` check.
Added tests with pointer arithmetic in template functions to make test
cases more robust.
Closes https://github.com/llvm/llvm-project/issues/139241.
this PR fixes#126424
for `ArraySubScriptExpr`, `hasBase` Matcher will get right operand when
it is not integer type, but is not for sure that left operand is integer
type. For the example code below `hasBase` will get `r` for the
Subsequent matching and causing false positive.
```
template <typename R>
int f(std::map<R*, int>& map, R* r) {
return map[r];
}
```
so is needed to see if index is integer type to avoid this situation.
Since std::move is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (MoveFunction) provides a way to continue using this
essential check even with the custom implementation of moving.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Since std::forward is nothing more than a cast, part of STL and not the
language itself, it's easy to provide a custom implementation if one
wishes not to include the entirety of <utility>.
Added flag (ForwardFunction) provides a way to continue using this
essential check even with the custom implementation of forwarding.
---------
Co-authored-by: EugeneZelenko <eugene.zelenko@gmail.com>
Run misc-use-internal-linkage check over clang-tidy code.
Also fixed a couple of other clang-tidy warnings.
Apart from issues in header files, all '.cpp' in
`clang-tools-extra/clang-tidy` must be clang-tidy clear now.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
According to #116591.
> Coding guidelines should "cherry-pick" (and posddsibly
configure/harden/make more strict) base checks.
We should move narrowing conversion to bugprone and keep alias in
cppcoreguidelines
`hasSimpleCopyConstructor` series of functions are not reliable when
these functions are not resolved. We need to manually resolve the status
of these functions from its base classes.
Fixes: #111985.
Previously, the insertion location for the `= nullptr` fix would be
after the variable name. However, if the variable is of type function
pointer that is not an alias, then the insertion would happen inside the
type specification: `void (*a1)(void*);` -> `void (*a1 =
nullptr)(void*);`.
With this change, the insertion location will be at the next
'terminator'. That is, at the next `,` or `;`, as that will finish the
current declaration: `void (a1)(void*) = nullptr;`.
Fixes#112089
If a add_clang_library call doesn't specify building as static or shared
library they are implicitly added to the list static libraries that is
linked in to clang-cpp shared library here.
315ba77406/clang/cmake/modules/AddClang.cmake (L107)
Because the clang-tools-extra libraries targets were declared after
clang-cpp they by luck never got linked to clang-cpp.
This change is required for clang symbol visibility macros on windows to
work correctly for clang tools since we need to distinguish if a target
being built will be importing or exporting clang symbols from the
clang-cpp DLL.
Fixes: #82970
Detecting dependiences with `varDecl` is too strict. It will ignore the
`bingingDecl`.
This patch wants to use `valueDecl` to match more cases including
`bingingDecl`.
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.
Improved cppcoreguidelines-special-member-functions check with a new
option AllowImplicitlyDeletedCopyOrMove, which removes the requirement
for explicit copy or move special member functions when they are already
implicitly deleted.
Closes#62392
Try to fix https://github.com/llvm/llvm-project/issues/83845
When `std::forward` is invoked in a function, make sure it uses correct
parameter by checking if the bounded `var` equals the parameter.
Co-authored-by: huqizhi <836744285@qq.com>
This functionality already exists in
cppcoreguidelines-use-default-member-init. It was deprecated from this
check in clang-tidy 17.
This allows us to fully decouple this check from the corresponding
modernize check, which has an unhealthy dependency.
Fixes https://github.com/llvm/llvm-project/issues/62169
---------
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
Produces now valid fixes for a member variables initialized with macros.
Correctly uses expansion location instead of location inside macro to
get init code.
Close#70189
Parameter variable which is forwarded in lambda capture list or in body
by reference is reasonable and current version of this check produces
false positive on these cases. This patch try to fix the
[issue](https://github.com/llvm/llvm-project/issues/68105)
Co-authored-by: huqizhi <836744285@qq.com>
Improved cppcoreguidelines-pro-type-const-cast check to ignore casts to
const type (controlled by option) and casts in implicitly invoked code.
Fixes#69319
