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 commit handles the following types:
- clang::ExternalASTSource
- clang::TargetInfo
- clang::ASTContext
- clang::SourceManager
- clang::FileManager
Part of cleanup #151026
Introduce the `reentrant_capability` attribute, which may be specified
alongside the `capability(..)` attribute to denote that the defined
capability type is reentrant. Marking a capability as reentrant means
that acquiring the same capability multiple times is safe, and does not
produce warnings on attempted re-acquisition.
The most significant changes required are plumbing to propagate if the
attribute is present to a CapabilityExpr, and introducing
ReentrancyDepth to the LockableFactEntry class.
The passed indices have to be constant integers anyway, which we verify
before creating the ShuffleVectorExpr. Use the value we create there and
save the indices using a ConstantExpr instead. This way, we don't have
to evaluate the args every time we call getShuffleMaskIdx().
Some of the old lock-based and new capability-based spellings behave
basically in the same way, so merging them simplifies the code
significantly.
There are two minor functional changes: we only warn (instead of an
error) when the try_acquire_capability attribute is used on something
else than a function. The alternative would have been to produce an
error for the old spelling, but we seem to only warn for all function
attributes, so this is arguably more consistent.
The second change is that we also check the first argument (which is the
value returned for a successful try-acquire) for `this`. But from what I
can tell, this code is defunct anyway at the moment (see #31414).
This introduces a new class 'UnsignedOrNone', which models a lite
version of `std::optional<unsigned>`, but has the same size as
'unsigned'.
This replaces most uses of `std::optional<unsigned>`, and similar
schemes utilizing 'int' and '-1' as sentinel.
Besides the smaller size advantage, this is simpler to serialize, as its
internal representation is a single unsigned int as well.
For deduction guides generated from alias template CTAD, store the
deduction guide they were originated from. The source kind is also
maintained for future expansion in CTAD from inherited constructors.
This tracking is required to determine whether an alias template already
has a deduction guide corresponding to some deduction guide on the
original template, in order to support deduction guides for the alias
from deduction guides declared after the initial usage.
We used to copy the `SourceLocation` instead of importing it, which
isn't correct since the `SourceManager`'s of the source and target
ASTContext might differ.
Also adds test that confirms that we import the explicit object
parameter location for `ParmVarDecl`s. This is how Clang determines
whether a parameter `isExplicitObjectParamater`. The LLDB expression
evaluator relies on this for calling "explicit object member functions".
`ASTImporterLookupTable` did use the `getPrimaryContext` function to get
the declaration context of the inserted items. This is problematic
because the primary context can change during import of AST items, most
likely if a definition of a previously not defined class is imported.
(For any record the primary context is the definition if there is one.)
The use of primary context is really not important, only for namespaces
because these can be re-opened and lookup in one namespace block is not
enough. This special search is now moved into ASTImporter instead of
relying on the lookup table.
This reverts commit 81fc3add1e627c23b7270fe2739cdacc09063e54.
This breaks some LLDB tests, e.g.
SymbolFile/DWARF/x86/no_unique_address-with-bitfields.cpp:
lldb: ../llvm-project/clang/lib/AST/Decl.cpp:4604: unsigned int clang::FieldDecl::getBitWidthValue() const: Assertion `isa<ConstantExpr>(getBitWidth())' failed.
Save the bitwidth value as a `ConstantExpr` with the value set. Remove
the `ASTContext` parameter from `getBitWidthValue()`, so the latter
simply returns the value from the `ConstantExpr` instead of
constant-evaluating the bitwidth expression every time it is called.
Note that PointerUnion::get has been soft deprecated in
PointerUnion.h:
// FIXME: Replace the uses of is(), get() and dyn_cast() with
// isa<T>, cast<T> and the llvm::dyn_cast<T>
This fix applies to a case that occurs when the AST contains a friend
template that is contained within another template and this (outer)
template has specialization. (See the added test code in the commit.)
After commits 9c72a30 and 30a9cac error handling in function
'importTemplateParameterDefaultArgument' was not correct,
probably related to (not) using std::move. A crash with unchecked
Error result could happen when the import error path was taken.
Here a test is added that reproduces this case and the problem is
fixed.
Commit e4440b8 added a change that introduced new crash in an
incorrectly handled case. This is fixed here. Default argument
definition or inheritance is preserved in the "To" AST compared to
the "From". If the default argument is defined already in the "To"
AST it can be duplicated at the import.
This fixes infinite recursion crash on return with UnaryTransformType,
whose underlying type is a SubstTemplateTypeParmType which is
associated with current imported function.
Lambdas without trailing return could also have return type defined
inside its body.
This fixes crashes (infinite recursion) on lambda expr without
parameters (no parentheses).
Default values of template parameters (non-type, type, template) were
not correctly handled in the "inherited" case. This occurs if the first
declaration contains the default value but a next one not. The default
value is "inherited" from the first.
In ASTImporter it was only possible to set the inherited status after
the template object was created with the template parameters that were
imported without handling the inherited case. The import function of the
template parameter contains not enough information (previous
declaration) to set the inherited-from status. After the template was
created, default value of the parameters that should be inherited is
reset to inherited mode.
This reverts commit 88e5206f2c96a34e23a4d63f0a38afb2db044f0a. The
original change went in a while ago (last year) in
https://reviews.llvm.org/D145057. The specific reason I'm proposing a
revert is that this is now causing exactly the issue that @balazske
predicted in https://reviews.llvm.org/D145057#4164717:
> Problematic case is if the attribute has pointer to a Decl or Type
that is imported here in a state when the field is already created but
not initialized. Another problem is that attributes are added a second
time in Import(Decl *)
This now came up in the testing of LLDB support for
https://github.com/llvm/llvm-project/issues/93069. There,
`__compressed_pair`s are now replaced with fields that have an
`alignof(...)` and `[[no_unique_address]]` attribute. In the specific
failing case, we're importing following `std::list` method:
```
size_type& __sz() _NOEXCEPT { return __size_; }
```
During this process, we create a new `__size_` `FieldDecl` (but don't
initialize it yet). Then we go down the `ImportAttrs` codepath added in
D145057. This imports the `alignof` expression which then references the
uninitialized `__size_` and we trigger an assertion.
Important to note, this codepath was added specifically to support
`[[no_unique_address]]` in LLDB, and was supposed to land with
https://reviews.llvm.org/D143347. But the LLDB side of that never
landed, and the way we plan to support `[[no_unique_address]]` doesn't
require things like the `markEmpty` method added here. So really, this
is a dead codepath, which as pointed out in the original review isn't
fully sound.
These tests are for multiple anonymous EnumDecls structural eq test &
importing.
We found the anonymous enums importing issue a few days ago and tried to
fix it
but 0a6233a68c7b575d05bca0f0c708b7e97cc710d1 already did this. I think
these tests are still useful for regressions.
After changes in PR #87144 and #93923 regressions appeared in some
cases. The problem was that if multiple anonymous enums are present in a
class and are imported as new the import of the second enum can fail
because it is detected as different from the first and causes ODR error.
Now in case of enums without name an existing similar enum is searched,
if not found the enum is imported. ODR error is not detected. This may
be incorrect if non-matching structures are imported, but this is the
less important case (import of matching classes is more important to
work).
This PR reverts #95290 and the one-liner followup PR #96494.
I received some substantial feedback on #95290, which I plan to address
in a future PR.
I've also received feedback that because the change emits errors where
they were not emitted before, we should at least have a flag to disable
the stricter warnings.
With this change, Clang will generate errors when trylock functions have
improper return types. Today, it silently fails to apply the trylock
attribute to these functions which may incorrectly lead users to believe
they have correctly acquired locks before accessing guarded data.
As a side effect of explicitly checking the success argument type, I
seem to have fixed a false negative in the analysis that could occur
when a trylock's success argument is an enumerator. I've added a
regression test to warn-thread-safety-analysis.cpp named
`TrylockSuccessEnumFalseNegative`.
This change also improves the documentation with descriptions of of the
subtle gotchas that arise from the analysis interpreting the success arg
as a boolean.
Issue #92408
Don't skip searching in `ToContext` during importing `EnumDecl`. And
`IsStructuralMatch` in `StructralEquivalence` can make sure to determine
whether the found result is match or not.
---------
Co-authored-by: huqizhi <836744285@qq.com>
This is an enabler for https://github.com/llvm/llvm-project/pull/92855
This allows an NTTP default argument to be set as an arbitrary
TemplateArgument, not just an expression.
This allows template parameter packs to have default arguments in the
AST, even though the language proper doesn't support the syntax for it.
This allows NTTP default arguments to be other kinds of arguments, like
packs, integral constants, and such.
This is an enabler for a future patch.
This allows an type-parameter default argument to be set as an arbitrary
TemplateArgument, not just a type.
This allows template parameter packs to have default arguments in the
AST, even though the language proper doesn't support the syntax for it.
This will be used in a later patch which synthesizes template parameter
lists with arbitrary default arguments taken from template
specializations.
There are a few places we used SubsType, because we only had a type, now
we use SubstTemplateArgument.
SubstTemplateArgument was missing arguments for setting Instantiation
location and entity names.
Adding those is needed so we don't regress in diagnostics.
Fix crash in the testcase from
https://github.com/llvm/llvm-project/issues/75114#issuecomment-1872595956
Forget to set inline of variable declaration would make
`isThisDeclarationADefinition` get incorrect result and didn't get
imported variable. This will lead to a new `VarTemplateDecl` being
created and call `setDescribedVarTemplate` again which produces the
crash.
Co-authored-by: huqizhi <836744285@qq.com>
Code of `VisitVarTemplateSpecializationDecl` was rewritten based on code
of `VisitVarDecl`. Additional changes (in structural equivalence) were
made to make tests pass.
Adds support for the following matchers related to `CXXFoldExpr`:
`cxxFoldExpr`, `callee`,
`hasInit`, `hasPattern`, `isRightFold`, `isLeftFold`,
`isUnaryFold`, `isBinaryFold`, `hasOperator`, `hasLHS`, `hasRHS`.
In some cases variable templates (specially if static member of record)
were not correctly imported and an assertion "Missing call to
MapImported?" could happen.
A friend template that is in a dependent context is not linked into
declaration chains (for example with the definition of the befriended
template). This condition was not correctly handled by `ASTImporter`.
import of `ClassTemplateSpecializationDecl` didn't set
`InstantiatedFromMember` and this makes ast-dump crash. import and set
`InstantiatedFromMember`. fix
[issue](https://github.com/llvm/llvm-project/issues/76469)
Co-authored-by: huqizhi <836744285@qq.com>
Since import `ExplicitCastExpr` lacks of processing
`BuiltinBitCastExprClass` type, it would reach to the 'unreachable' code
and produce the crash. This patch aims to fix the
[crash](https://github.com/llvm/llvm-project/issues/74774) and try to
handle `BuiltinBitCastExpr`.
Co-authored-by: huqizhi <836744285@qq.com>
Expression of attribute `align_value` was not imported. Import of the
attribute is corrected, a test for it is added, other related tests with
FIXME are updated.
Fixes#75054.
Lack of processing of `SubstNonTypeTemplateParmExpr` in
`isAncestorDeclContextOf` would make `hasAutoReturnTypeDeclaredInside`
returns false and lead to infinite recursion. This patch adds the
processor and try to fix [this
issue](https://github.com/llvm/llvm-project/issues/74839)
Co-authored-by: huqizhi <836744285@qq.com>
Import of a function with `auto` return type that is expanded to a
`SubstTemplateTypeParmType` could fail if the function itself is the
template specialization where the parameter was replaced.
