* Mark SVE ACLE types as substitution candidates.
* Change mangling of svbfloat16_t from __SVBFloat16_t to
__SVBfloat16_t.
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst
This is an ABI break with the old behaviour available via
"-fclang-abi-compat=17".
A problem with AST import could lead to multiple instances of the same
template class specialization, with different template arguments. The
difference was caused by pointers to different declarations of the same
function.
Problem is fixed by using the canonical declaration at import.
Co-authored-by: Balázs Kéri <balazs.keri@ericsson.com>
The last use of StringMap was removed by:
commit 20157410862d376c624cc24bffd9730290a16142
Author: Vince Bridgers <vince.a.bridgers@gmail.com>
Date: Thu Jul 16 12:55:32 2020 -0500
[clang][ASTImporter] Fix crash when import `VarTemplateDecl` in record
static VarTemplateDecl in record isn't a definition, when imported
before, it will crash in `ASTContext::setTemplateOrSpecializationInfo`
due to setting specialization while it already exists. This patch skip
this specific case.
Co-authored-by: huqizhi <836744285@qq.com>
This patch reland 54c1a9b20d89e85cd60d002c77b34c00f36520f4, which
updates GoogleTest to v1.14.0. This patch fixes bots failures caused
by the early patch.
Pointer comparison is not reliable in this case. Use ASTStructuralEquivalence
to compute FriendCountAndPosition.
Reviewed By: balazske
Differential Revision: https://reviews.llvm.org/D157684
Depth of the parameter of friend template class declaration in a
template class is 1, while in the specialization the depth is 0.
This will cause failure on 'IsStructurallyEquivalent' as a name
conflict in 'VisitClassTemplateDecl'(see testcase of
'SkipComparingFriendTemplateDepth'). The patch fix it by ignore
the depth only in this special case.
Reviewed By: balazske
Differential Revision: https://reviews.llvm.org/D156693
UnaryOperator(&)'s creation might need layout of some records
whose fields importation are still on fly, the layout is incorrectly
computed and cached. Clients relying on this will not work properly
or crash direclty (e.g StaticAnalyzer's MemRegion.cpp (calculateOffset)).
Use UnaryOperator::CreateEmpty() instead of UnaryOperator::Create()
to avoid this computation.
Fixes https://github.com/llvm/llvm-project/issues/64170
Reviewed By: aaron.ballman, balazske, shafik
Differential Revision: https://reviews.llvm.org/D156201
For friend class template within dependent context:
1. Should not do structure matching checking. This fixes importing failure of
template with non-type parm;
2. Should not be added into redecls chain.
See Sema::CheckClassTemplate().
Fixes https://github.com/llvm/llvm-project/issues/64169.
Reviewed By: aaron.ballman, balazske, shafik
Differential Revision: https://reviews.llvm.org/D155661
Import of field initializers with circular reference was not working,
this is fixed now.
Fixes issue #63120
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D155574
Fields are imported first and reordered for correct layout.
For partially imported record, layout computation is incorrect.
Differential Revision: https://reviews.llvm.org/D154764
CXXMethodDecl::isVirtual() count the number of overridden methods.
This assertion is not true before overridden methods are fully loaded.
The body of this CXXMethodDecl can introduce deps on a derived class
which contains a method overriding this method, causing the assertion failure.
ImportOverriddenMethods() is moved before body loading to fix this issue.
Testcase is contributed by Balázs Kéri (balazske)
Differential Revision: https://reviews.llvm.org/D154701
Fix crash in ASTImporter related to import of unnamed structures and typedefs
to these maybe with pointer.
There was a series of problems exposed by https://reviews.llvm.org/D133468
(commit 69a6417406a1b0316a1fa6aeb63339d0e1d2abbd) in the ASTImporter breaking
cross-translation unit analysis. This change fixes one of the problems exposed
by that change for importing unnamed structures. The problem was
discovered when running clang static analysis on open source projects
using cross-translation unit analysis.
Simple test command. Produces crash without change, passes all tests
with change.
```
ninja ASTTests && ./tools/clang/unittests/AST/ASTTests
--gtest_filter="*/*ImportAnonymousStruct/0"
```
Formatted crash stack:
```
ASTTests: <root>/clang/lib/AST/ASTContext.cpp:4787:
clang::QualType clang::ASTContext::getTypedefType(const clang::TypedefNameDecl*,
clang::QualType) const: Assertion `hasSameType(Decl->getUnderlyingType(), Underlying)' failed.
...
#9 <addr> clang::ASTContext::getTypedefType(clang::TypedefNameDecl const*, clang::QualType) const
<root>/clang/lib/AST/ASTContext.cpp:4789:26
<root>/clang/lib/AST/ASTImporter.cpp:1374:71
<root>/tools/clang/include/clang/AST/TypeNodes.inc:75:1
<root>/clang/lib/AST/ASTImporter.cpp:8663:8
```
Reviewed By: donat.nagy
Differential Revision: https://reviews.llvm.org/D145868
When a typedef node is imported, ASTImporter should not find an existing similar
typedef node for it that comes from different context (translation unit or scope).
This should avoid a situation where an existing typedef declaration is returned
at import of a typedef, but the underlying type was already imported as a new
type object.
Reviewed By: vabridgers
Differential Revision: https://reviews.llvm.org/D145479
Patch represents the clang part of changes in D143347
Reviewed By: balazske
Differential Revision: https://reviews.llvm.org/D145057
~~
Huawei RRI, OS Lab
Add '__builtin_FILE_NAME()', which expands to the filename because the
full path is not always needed. It corresponds to the '__FILE_NAME__'
predefined macro and is consistent with the other '__builin' functions
added for predefined macros.
Differential Revision: https://reviews.llvm.org/D144878
The declaration of __builtin_va_list seems to be handled specially
by ASTContext and/or Sema. The normal AST traversal probably can
not find it, therefore it is not added to ASTImporterLookupTable.
If it is not added, errors can occur because a duplicated
VaList declaration is created at import. To fix the problem the
VaList declaration is added manually to ASTImporterLookupTable
at construction.
In special cases this declaration is inside a "invisible" 'std'
namespace that behaves the same way. This namespace must be added
to the table too.
Reviewed By: vabridgers, donat.nagy
Differential Revision: https://reviews.llvm.org/D144273
This is a fix for a problem when multiple template
specializations are created by ASTImporter for the
same specialization. The problem happens if a
TemplateName is imported that points to a template
delcaration (for a template template argument)
(specialization) that has multiple instances in the
declaration chain. If two TemplateName objects contain
different pointers to a template specialization,
these TemplateName objects will have different checksum
even if they point into the same declaration chain.
The problem is fixed if the canonical declaration is used.
Reviewed By: vabridgers, donat.nagy
Differential Revision: https://reviews.llvm.org/D144622
During AST import multiple different InjectedClassNameType objects
could be created for a single class template. This can cause problems
and failed assertions when these types are compared and found to be
not the same (because the instance is different and there is no
canonical type).
The import of this type does not use the factory method in ASTContext,
probably because the preconditions are not fulfilled at that state.
The fix tries to make the code in ASTImporter work more like the code
in ASTContext::getInjectedClassNameType. If a type is stored at the
Decl or previous Decl object, it is reused instead of creating a new
one. This avoids crash at least a part of the cases.
Reviewed By: gamesh411, donat.nagy, vabridgers
Differential Revision: https://reviews.llvm.org/D140562
ASTImporterLookupTable did not handle correctly friend declarations
where the friend type is an UsingType (type of a declaration that
comes from an using-declaration). The problem is fixed by handling
it in the same way as a friend with TypedefType.
Reviewed By: steakhal
Differential Revision: https://reviews.llvm.org/D142607
With https://reviews.llvm.org/D141826 `TemplateArgument`s have an
additional field that indicates their defaulted-ness. This gets
used during debug-info generation and in the `clang::TypePrinter`.
This patch copies the field during the import process so consumers
of the ASTImporter can benefit from the other Clang components that
read the field.
**Testing**
* Added unit-test
* Checked that this fixes (in addition to a follow-up LLDB patch)
fix current test failures in LLDB
Differential Revision: https://reviews.llvm.org/D142713
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
This fixes a problem where __va_list_tag was not correctly imported,
possibly leading to multiple definitions with different types.
This adds __va_list_tag to it's proper scope, so that the ASTImporter
can find it.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D136886
The uncached lookup is mainly used in the ASTImporter/LLDB code-path
where we're not allowed to load from external storage. When importing
a FieldDecl with a DeclContext that had no external visible storage
(but came from a Clang module or PCH) the above call to `lookup(Name)`
the regular `DeclContext::lookup` fails because:
1. `DeclContext::buildLookup` doesn't set `LookupPtr` for decls
that came from a module
2. LLDB doesn't use the `SharedImporterState`
In such a case we would never continue with the "slow" path of iterating
through the decl chain on the DeclContext. In some cases this means that
ASTNodeImporter::VisitFieldDecl ends up importing a decl into the
DeclContext a second time.
The patch removes the short-circuit in the case where we don't find
any decls via the regular lookup.
**Tests**
* Un-skip the failing LLDB API tests
Differential Revision: https://reviews.llvm.org/D133945
ASTImporter used to crash in some cases when a function is imported with
`auto` return type and the return type has references into the function.
The handling of such cases is improved and crash should not occur any more
but it is not fully verified, there are very many different types of
cases to care for.
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D130705
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.
The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.
An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.
---
Troubleshooting list to deal with any breakage seen with this patch:
1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.
2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.
3) This patch could expose a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.
4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.
5) It could be a bug in this patch perhaps.
Let me know if you need any help!
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374
Avoid a crash if a function is imported that has auto return type that
references to a template with an expression-type of argument that
references into the function's body.
Fixes issue #56047
Reviewed By: martong
Differential Revision: https://reviews.llvm.org/D129640
This reverts commit 7c51f02effdbd0d5e12bfd26f9c3b2ab5687c93f because it
stills breaks the LLDB tests. This was re-landed without addressing the
issue or even agreement on how to address the issue. More details and
discussion in https://reviews.llvm.org/D112374.
Without this patch, clang will not wrap in an ElaboratedType node types written
without a keyword and nested name qualifier, which goes against the intent that
we should produce an AST which retains enough details to recover how things are
written.
The lack of this sugar is incompatible with the intent of the type printer
default policy, which is to print types as written, but to fall back and print
them fully qualified when they are desugared.
An ElaboratedTypeLoc without keyword / NNS uses no storage by itself, but still
requires pointer alignment due to pre-existing bug in the TypeLoc buffer
handling.
---
Troubleshooting list to deal with any breakage seen with this patch:
1) The most likely effect one would see by this patch is a change in how
a type is printed. The type printer will, by design and default,
print types as written. There are customization options there, but
not that many, and they mainly apply to how to print a type that we
somehow failed to track how it was written. This patch fixes a
problem where we failed to distinguish between a type
that was written without any elaborated-type qualifiers,
such as a 'struct'/'class' tags and name spacifiers such as 'std::',
and one that has been stripped of any 'metadata' that identifies such,
the so called canonical types.
Example:
```
namespace foo {
struct A {};
A a;
};
```
If one were to print the type of `foo::a`, prior to this patch, this
would result in `foo::A`. This is how the type printer would have,
by default, printed the canonical type of A as well.
As soon as you add any name qualifiers to A, the type printer would
suddenly start accurately printing the type as written. This patch
will make it print it accurately even when written without
qualifiers, so we will just print `A` for the initial example, as
the user did not really write that `foo::` namespace qualifier.
2) This patch could expose a bug in some AST matcher. Matching types
is harder to get right when there is sugar involved. For example,
if you want to match a type against being a pointer to some type A,
then you have to account for getting a type that is sugar for a
pointer to A, or being a pointer to sugar to A, or both! Usually
you would get the second part wrong, and this would work for a
very simple test where you don't use any name qualifiers, but
you would discover is broken when you do. The usual fix is to
either use the matcher which strips sugar, which is annoying
to use as for example if you match an N level pointer, you have
to put N+1 such matchers in there, beginning to end and between
all those levels. But in a lot of cases, if the property you want
to match is present in the canonical type, it's easier and faster
to just match on that... This goes with what is said in 1), if
you want to match against the name of a type, and you want
the name string to be something stable, perhaps matching on
the name of the canonical type is the better choice.
3) This patch could exposed a bug in how you get the source range of some
TypeLoc. For some reason, a lot of code is using getLocalSourceRange(),
which only looks at the given TypeLoc node. This patch introduces a new,
and more common TypeLoc node which contains no source locations on itself.
This is not an inovation here, and some other, more rare TypeLoc nodes could
also have this property, but if you use getLocalSourceRange on them, it's not
going to return any valid locations, because it doesn't have any. The right fix
here is to always use getSourceRange() or getBeginLoc/getEndLoc which will dive
into the inner TypeLoc to get the source range if it doesn't find it on the
top level one. You can use getLocalSourceRange if you are really into
micro-optimizations and you have some outside knowledge that the TypeLocs you are
dealing with will always include some source location.
4) Exposed a bug somewhere in the use of the normal clang type class API, where you
have some type, you want to see if that type is some particular kind, you try a
`dyn_cast` such as `dyn_cast<TypedefType>` and that fails because now you have an
ElaboratedType which has a TypeDefType inside of it, which is what you wanted to match.
Again, like 2), this would usually have been tested poorly with some simple tests with
no qualifications, and would have been broken had there been any other kind of type sugar,
be it an ElaboratedType or a TemplateSpecializationType or a SubstTemplateParmType.
The usual fix here is to use `getAs` instead of `dyn_cast`, which will look deeper
into the type. Or use `getAsAdjusted` when dealing with TypeLocs.
For some reason the API is inconsistent there and on TypeLocs getAs behaves like a dyn_cast.
5) It could be a bug in this patch perhaps.
Let me know if you need any help!
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D112374
