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
…heck
One typically only wants to perform renaming operations in user code,
not in system headers (which are out of the user's control). Let's skip
those altogether.
This leads to performance improvements in clang-tidy. As a benchmark, I
run all checks on a .cpp file that #includes all C++ standard headers.
On trunk:
```
Suppressed 213362 warnings (213362 in non-user code).
real 0m14.422s
user 0m14.236s
sys 0m0.184s
```
On this patch:
```
Suppressed 75411 warnings (75411 in non-user code).
real 0m12.472s
user 0m12.334s
sys 0m0.136s
```
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
These checks previously failed with absl::StrFormat and absl::PrintF
etc. with:
Unable to use 'std::format' instead of 'StrFormat' because first
argument is not a narrow string literal [modernize-use-std-format]
because FormatStringConverter was rejecting the format string if it had
already converted into a different type. Fix the tests so that they
check this case properly by accepting string_view rather than const char
* and fix the check so that these tests pass. Update the existing tests
that checked for the error message that can no longer happen.
Fixes: https://github.com/llvm/llvm-project/issues/129484
Before this patch, this check only handles `VarDecl` as varaibles
declaration in statement, but this will ignore variables in structured
bindings (`BindingDecl` in AST), which leads to false positives.
Closes#138842.
Add `NamespaceBaseDecl` as common base class of `NamespaceDecl` and
`NamespaceAliasDecl`. This simplifies `NestedNameSpecifier` a bit.
Co-authored-by: Matheus Izvekov <mizvekov@gmail.com>
This PR add stacktrace of escaped exception to
`bugprone-exception-escape` check.
Changes:
1. Modified `ExceptionAnalyzer` and `ExceptionInfo` classes to hold
stacktrace of escaped exception in `llvm::MapVector`. `llvm::MapVector`
is needed to hold relative positions of functions in stack as well as
have fast lookup.
2. Added new diagnostics based of `misc-no-recursion` check.
Fixes https://github.com/llvm/llvm-project/issues/87422.
C++17's CTAD obsoletes `makeMatcher` (and many `make*` functions like
it).
The deduction guide is written out explicitly to avoid
`-Wctad-maybe-unsupported` warnings.
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.
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.
This patch extends the canonicalization printing policy to cover
expressions
and template names, and wires that up to the template argument printer,
covering expressions, and to the expression within a dependent decltype.
This is helpful for debugging, or if these expressions somehow end up
in diagnostics, as without this patch they can print as completely
unrelated
expressions, which can be quite confusing.
This is because expressions are not uniqued, unlike types, and
when a template specialization containing an expression is the first to
be
canonicalized, the expression ends up appearing in the canonical type of
subsequent equivalent specializations.
Fixes https://github.com/llvm/llvm-project/issues/92292
We can safely switch to insert_range here because
SyntheticStmtSourceMap starts out empty in the constructor. Also
TheCFG->synthetic_stmts() comes from DenseMap, so we know that the
keys are unique. That is, operator[] and insert are equivalent in
this particular case.
Original PR: #130537
Originally reverted due to revert of dependent commit. Relanding with no
changes.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the base class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntatically, and
they represent the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements.
Original PR: #130537
Reland after updating lldb too.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the base class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntatically, and
they represent the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements.
This changes the MemberPointerType representation to use a
NestedNameSpecifier instead of a Type to represent the class.
Since the qualifiers are always parsed as nested names, there was an
impedance mismatch when converting these back and forth into types, and
this led to issues in preserving sugar.
The nested names are indeed a better match for these, as the differences
which a QualType can represent cannot be expressed syntactically, and it
also represents the use case more exactly, being either dependent or
referring to a CXXRecord, unqualified.
This patch also makes the MemberPointerType able to represent sugar for
a {up/downcast}cast conversion of the base class, although for now the
underlying type is canonical, as preserving the sugar up to that point
requires further work.
As usual, includes a few drive-by fixes in order to make use of the
improvements, and removing some duplications, for example
CheckBaseClassAccess is deduplicated from across SemaAccess and
SemaCast.
This PR fixes issue #124815 by correcting the handling of `nullptr` with
`std::unique_ptr` in the `modernize-use-ranges` check.
Updated the logic to suppress warnings for `nullptr` in `std::find`.
Normally endless recursion should not happen in ExceptionSpecAnalyzer,
but if AST would be malformed (missing include), this could cause crash.
I run into this issue when due to missing include constructor argument
were parsed as FieldDecl.
As checking for recursion cost nothing, why not to do this in check just
in case.
Fixes#111436
Similarly to https://github.com/llvm/llvm-project/pull/122918, leading
comments are currently not being moved.
```
struct Foo {
// This one is the cool field.
int a;
int b;
};
```
becomes:
```
struct Foo {
// This one is the cool field.
int b;
int a;
};
```
but should be:
```
struct Foo {
int b;
// This one is the cool field.
int a;
};
```
We have two copies of the same code in clang-tidy and
clang-reorder-fields, and those are extremenly similar to
`Lexer::findNextToken`, so just add an extra agument to the latter.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
`ExceptionAnalyzer` can ignore `consteval` function even if it will
throw exception. `consteval` function must produce compile-time
constant. But throw statement cannot appear in constant evaluation.
Fixed: #104457.
This patch improves, but doens't fully resolve the layering violation,
which stems from relying on Sema. There's one function that needs to
convert enumerator to a string (`buildQualifier` in
`FixItHintUtils.cpp`), but `Qualifiers::TQ` doesn't offer such function.
Even more, the set of enumerators is not complete compared to
`DeclSpec::TQ`, so I'm afraid that this would be a functional change.
Expanding all macros in the printf/absl::StrFormat format string before
conversion could easily break code if those macros are expanded change
their definition between builds. It's important for this check to expand
the <inttypes.h> PRI macros though, so let's ensure that the presence of
any other macros in the format string causes the check to emit a warning
and not perform any conversion.
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.
Adds the check option `bugprone-unsafe-functions.CustomFunctions` to be
able to match user-defined functions as part of the checker.
Adds the option `bugprone-unsafe-functions.ReportDefaultFunctions` to
disable reporting the default set of functions as well.
The functions names are matched using the same mechanism as the
`matchesAnyListedName` tidy matcher, documented in
`unsafe-functions.rst`.
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
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.
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>
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`)
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>
…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];
}
```
Ensure that FormatStringConverter's constructor fails with a sensible
error message rather than asserting if the format string is not a narrow
string literal.
Also, ensure that we don't even get that far in modernize-use-std-print
and modernize-use-std-format by checking that the format string
parameter is a char pointer.
Fixes#92896
Member function templates defined out-of-line were resulting in
conflicting naming failures with overlapping usage sets. With this
change, out-of-line definitions are treated as a usage of the failure
which is the inline declaration.
Add a new clang-tidy check that converts absl::StrFormat (and similar
functions) to std::format (and similar functions.)
Split the configuration of FormatStringConverter out to a separate
Configuration class so that we don't risk confusion by passing two
boolean configuration parameters into the constructor. Add
AllowTrailingNewlineRemoval option since we never want to remove
trailing newlines in this check.
