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.
These are an artifact of how types are structured but serve little
purpose, merely showing that the type is sugared in some way. For
example, ElaboratedType's existence means struct S gets printed as
'struct S':'struct S' in the AST, which is unnecessary visual clutter.
Note that skipping the second print when the types have the same string
matches what we do for diagnostics, where the aka will be skipped.
* 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
