We reorder declarations in RecordDecls because they may have another order
in the "to" context than they have in the "from" context. This may happen
e.g when we import a class like this:
struct declToImport {
int a = c + b;
int b = 1;
int c = 2;
};
During the import of `a` we import first the dependencies in sequence,
thus the order would be `c`, `b`, `a`. We will get the normal order by
first removing the already imported members and then adding them in the
order as they apper in the "from" context.
Keeping field order is vital because it determines structure layout.
Reviewers: a_sidorin, shafik
Tags: #clang
Differential Revision: https://reviews.llvm.org/D44100
llvm-svn: 366997
Summary:
A new function will be added to get the original SourceLocation
for a SourceLocation that was imported as result of getCrossTUDefinition.
The returned SourceLocation is in the context of the (original)
SourceManager for the original source file. Additionally the
ASTUnit object for that source file is returned. This is needed
to get a SourceManager to operate on with the returned source location.
The new function works if multiple different source files are loaded
with the same CrossTU context.
Reviewers: martong, shafik
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D65064
llvm-svn: 366884
Reason: the commit breaks layering by adding a dependency on ASTUnit
(which is inside clangFrontend) from the ASTImporter (which is inside
clangAST).
llvm-svn: 366453
Summary:
A new function will be added to get the original SourceLocation
for a SourceLocation that was imported as result of getCrossTUDefinition.
The returned SourceLocation is in the context of the (original)
SourceManager for the original source file. Additionally the
ASTUnit object for that source file is returned. This is needed
to get a SourceManager to operate on with the returned source location.
The new function works if multiple different source files are loaded
with the same CrossTU context.
This patch can be treated as part of a bigger change that is needed to
improve macro expansion handliong at plist generation.
Reviewers: martong, shafik, a_sidorin, xazax.hun
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64554
llvm-svn: 366449
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage. The solution is to use noload_lookup, which
works well with transparent contexts. But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.
These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().
We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.
Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61333
llvm-svn: 366325
Summary:
ASTImporter makes now difference between enums with same name in different translation
units if these are not visible outside.
("Scoped enums" are not handled yet.)
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62484
llvm-svn: 365464
Summary:
The current import implementation fails to import the definition of a
lambda class if the lambda class is defined in a function param.
E.g., the lambda class below will be imported without any methods:
```
template <typename F>
void f(F L = [](){}) {}
```
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64073
llvm-svn: 365315
Summary:
Now we store the errors for the Decls in the "to" context too. For
that, however, we have to put these errors in a shared state (among all
the ASTImporter objects which handle the same "to" context but different
"from" contexts).
After a series of imports from different "from" TUs we have a "to" context
which may have erroneous nodes in it. (Remember, the AST is immutable so
there is no way to delete a node once we had created it and we realized
the error later.) All these erroneous nodes are marked in
ASTImporterSharedState::ImportErrors. Clients of the ASTImporter may
use this as an input. E.g. the static analyzer engine may not try to
analyze a function if that is marked as erroneous (it can be queried via
ASTImporterSharedState::getImportDeclErrorIfAny()).
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62376
llvm-svn: 364785
Summary:
During import of a specific Decl D, it may happen that some AST nodes
had already been created before we recognize an error. In this case we
signal back the error to the caller, but the "to" context remains
polluted with those nodes which had been created. Ideally, those nodes
should not had been created, but that time we did not know about the
error, the error happened later. Since the AST is immutable (most of
the cases we can't remove existing nodes) we choose to mark these nodes
as erroneous.
Here are the steps of the algorithm:
1) We keep track of the nodes which we visit during the import of D: See
ImportPathTy.
2) If a Decl is already imported and it is already on the import path
(we have a cycle) then we copy/store the relevant part of the import
path. We store these cycles for each Decl.
3) When we recognize an error during the import of D then we set up this
error to all Decls in the stored cycles for D and we clear the stored
cycles.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62375
llvm-svn: 364771
Summary:
During analysis of one project we failed to import one
CXXDestructorDecl. But since we did not propagate the error in
importDeclContext we had a CXXRecordDecl without a destructor. Then the
analyzer engine had a CallEvent where the nonexistent dtor was requested
(crash).
Solution is to propagate the errors we have during importing a
DeclContext.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D63603
llvm-svn: 364752
Summary:
We add a new member which is a mapping from the already-imported
declarations in the "from" context to the error status of the import of
that declaration. This map contains only the declarations that were not
correctly imported. The same declaration may or may not be included in
ImportedDecls. This map is updated continuously during imports and never
cleared (like ImportedDecls). In Import(Decl*) we use this mapping, so
if there was a previous failed import we return with the existing error.
We add/remove from the Lookuptable in consistency with ImportedFromDecls.
When we map a decl in the 'to' context to something in the 'from'
context then and only then we add it to the lookup table. When we
remove a mapping then and only then we remove it from the lookup table.
This patch is the first in a series of patches whose aim is to further
strengthen the error handling in ASTImporter.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62373
llvm-svn: 364279
Summary:
When using ConstantExpr we often need the result of the expression to be kept in the AST. Currently this is done on a by the node that needs the result and has been done multiple times for enumerator, for constexpr variables... . This patch adds to ConstantExpr the ability to store the result of evaluating the expression. no functional changes expected.
Changes:
- Add trailling object to ConstantExpr that can hold an APValue or an uint64_t. the uint64_t is here because most ConstantExpr yield integral values so there is an optimized layout for integral values.
- Add basic* serialization support for the trailing result.
- Move conversion functions from an enum to a fltSemantics from clang::FloatingLiteral to llvm::APFloatBase. this change is to make it usable for serializing APValues.
- Add basic* Import support for the trailing result.
- ConstantExpr created in CheckConvertedConstantExpression now stores the result in the ConstantExpr Node.
- Adapt AST dump to print the result when present.
basic* : None, Indeterminate, Int, Float, FixedPoint, ComplexInt, ComplexFloat,
the result is not yet used anywhere but for -ast-dump.
Reviewers: rsmith, martong, shafik
Reviewed By: rsmith
Subscribers: rnkovacs, hiraditya, dexonsmith, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D62399
llvm-svn: 363493
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html
with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.
Changes:
- add the consteval keyword.
- add parsing of consteval specifier for normal declarations and lambdas expressions.
- add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
- adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
- add tests for basic semantic.
Reviewers: rsmith, martong, shafik
Reviewed By: rsmith
Subscribers: eraman, efriedma, rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61790
llvm-svn: 363362
Summary:
In most cases the FriendDecl contains the declaration of the befriended
class as a child node, so it is discovered during the recursive
visitation. However, there are cases when the befriended class is not a
child, thus it must be fetched explicitly from the FriendDecl, and only
then can we add it to the lookup table.
(Note, this does affect only CTU and does not affect LLDB, because we
cannot and do not use the ASTImporterLookupTable in LLDB.)
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62064
llvm-svn: 363062
Syntax:
asm [volatile] goto ( AssemblerTemplate
:
: InputOperands
: Clobbers
: GotoLabels)
https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html
New llvm IR is "callbr" for inline asm goto instead "call" for inline asm
For:
asm goto("testl %0, %0; jne %l1;" :: "r"(cond)::label_true, loop);
IR:
callbr void asm sideeffect "testl $0, $0; jne ${1:l};", "r,X,X,~{dirflag},~{fpsr},~{flags}"(i32 %0, i8* blockaddress(@foo, %label_true), i8* blockaddress(@foo, %loop)) #1
to label %asm.fallthrough [label %label_true, label %loop], !srcloc !3
asm.fallthrough:
Compiler need to generate:
1> a dummy constarint 'X' for each label.
2> an unique fallthrough label for each asm goto stmt " asm.fallthrough%number".
Diagnostic
1> duplicate asm operand name are used in output, input and label.
2> goto out of scope.
llvm-svn: 362045
Summary:
ASTImporter makes now difference between classes with same name in different
translation units if these are not visible outside. These classes are not linked
into one decl chain.
Reviewers: martong, a.sidorin, shafik
Reviewed By: shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62312
llvm-svn: 361752
Summary:
https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitRecordDecl for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via D->getTypedefNameForAnonDecl()->getDeclName().
This fix is very similar to https://reviews.llvm.org/D59665
Differential Revision: https://reviews.llvm.org/D62352
llvm-svn: 361650
Summary:
This patch implements the source location builtins `__builtin_LINE(), `__builtin_FUNCTION()`, `__builtin_FILE()` and `__builtin_COLUMN()`. These builtins are needed to implement [`std::experimental::source_location`](https://rawgit.com/cplusplus/fundamentals-ts/v2/main.html#reflection.src_loc.creation).
With the exception of `__builtin_COLUMN`, GCC also implements these builtins, and Clangs behavior is intended to match as closely as possible.
Reviewers: rsmith, joerg, aaron.ballman, bogner, majnemer, shafik, martong
Reviewed By: rsmith
Subscribers: rnkovacs, loskutov, riccibruno, mgorny, kunitoki, alexr, majnemer, hfinkel, cfe-commits
Differential Revision: https://reviews.llvm.org/D37035
llvm-svn: 360937
Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves the following:
- remove old Import functions which returned with a pointer,
- use the Import_New functions (which return with Err or Expected) everywhere
and handle their return value
- rename Import_New functions to Import
This affects both Clang and LLDB.
Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61438
llvm-svn: 360760
template name is not visible to unqualified lookup.
In order to support this without a severe degradation in our ability to
diagnose typos in template names, this change significantly restructures
the way we handle template-id-shaped syntax for which lookup of the
template name finds nothing.
Instead of eagerly diagnosing an undeclared template name, we now form a
placeholder template-name representing a name that is known to not find
any templates. When the parser sees such a name, it attempts to
disambiguate whether we have a less-than comparison or a template-id.
Any diagnostics or typo-correction for the name are delayed until its
point of use.
The upshot should be a small improvement of our diagostic quality
overall: we now take more syntactic context into account when trying to
resolve an undeclared identifier on the left hand side of a '<'. In
fact, this works well enough that the backwards-compatible portion (for
an undeclared identifier rather than a lookup that finds functions but
no function templates) is enabled in all language modes.
llvm-svn: 360308
Summary:
Structural equivalence of methods can falsely report false when the
exception specifier is unresolved (i.e unevaluated or not instantiated).
(This caused one assertion during bitcoin ctu-analysis.)
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61424
llvm-svn: 360261
This caused Clang to start erroring on the following:
struct S {
template <typename = int> explicit S();
};
struct T : S {};
struct U : T {
U();
};
U::U() {}
$ clang -c /tmp/x.cc
/tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T'
U::U() {}
^
/tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted
because base class 'S' has no default constructor
struct T : S {};
^
1 error generated.
See discussion on the cfe-commits email thread.
This also reverts the follow-ups r359966 and r359968.
> this patch adds support for the explicit bool specifier.
>
> Changes:
> - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
> - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
> - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
> - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
> - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
> - Test for Semantic and Serialization were added.
>
> This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
> Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
>
> Patch by Tyker
>
> Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 360024
new expression.
This was voted into C++20 as a defect report resolution, so we
retroactively apply it to all prior language modes (though it can never
actually be used before C++11 mode).
llvm-svn: 360006
this patch adds support for the explicit bool specifier.
Changes:
- The parsing for the explicit(bool) specifier was added in ParseDecl.cpp.
- The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class.
- Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted.
- Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration.
- The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected.
- Test for Semantic and Serialization were added.
This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback.
Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky.
Patch by Tyker
Differential Revision: https://reviews.llvm.org/D60934
llvm-svn: 359949
Summary:
We are currently implementing support in LLDB that reconstructs the STL templates from
the target program in the expression evaluator. This reconstruction happens during the
import process from our debug info AST into the expression evaluation AST, which means
we need a way to intercept the ASTImporter import process.
This patch adds an protected ImportImpl method that we can overwrite in LLDB to implement
our special importing logic (which is essentially just looking into a C++ module that is attached to
the target context). Because ImportImpl has to call MapImported/AddToLookup for the decls it
creates, this patch also exposes those via a new unified method and checks that we call it when
importing decls.
Reviewers: martong, balazske, a.sidorin, shafik, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: rnkovacs, cfe-commits, lldb-commits, aprantl
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59485
llvm-svn: 359502
Summary:
For a CXXRecordDecl the RecordDeclBits are stored in the DeclContext. Currently when we import the definition of a CXXRecordDecl via the ASTImporter we do not copy over this data.
This change will add support for copying the ArgPassingRestrictions from RecordDeclBits to fix an LLDB expression parsing bug where we would set it to not pass in registers.
Note, we did not copy over any other of the RecordDeclBits since we don't have tests for those. We know that copying over LoadedFieldsFromExternalStorage would be a error and that may be the case for others as well.
The companion LLDB review: https://reviews.llvm.org/D61146
Differential Review: https://reviews.llvm.org/D61140
llvm-svn: 359338
Summary:
https://reviews.llvm.org/D51633 added error handling to the ASTNodeImporter::VisitEnumDecl(...) for the conflicting names case. This could lead to erroneous return of an error in that case since we should have been using SearchName. Name may be empty in the case where we find the name via getTypedefNameForAnonDecl(...).
Differential Revision: https://reviews.llvm.org/D59665
llvm-svn: 357940
Summary:
ASTStructuralEquivalence uses a flag to indicate whether ODR diagnostics
should be considered errors or warnings as module Sema is more strict than
ASTMerge. The implementation of ASTImporter should allso follow
along the same lines.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: shafik, a_sidorin
Subscribers: rnkovacs, martong, dkrupp, Szelethus, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59761
Patch by Endre Fulop!
llvm-svn: 357402
Summary:
We may try and re-import an EnumDecl while trying to complete it in IsStructuralMatch(...) specialization for EnumDecl. This change mirrors a similar fix for the specialization for RecordDecl.
Differential Revision: https://reviews.llvm.org/D59845
llvm-svn: 357100
Summary:
The ASTNodeImporter::ImportTemplateParameterList is replaced by a
template specialization of 'import' that already exists and does
(almost) the same thing.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59134
llvm-svn: 356564
Summary:
Redecl chains of function template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58668
llvm-svn: 356455
Summary:
Redecl chains of class template specializations are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58673
llvm-svn: 356452
Summary:
This patch refactors several instances of cast<> used in if
conditionals. Since cast<> asserts on failure, the else branch can
never be taken.
In some cases, the fix is to replace cast<> with dyn_cast<>. While
others required the removal of the conditional and some minor
refactoring.
A discussion can be seen here: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20190318/265044.html
Differential Revision: https://reviews.llvm.org/D59529
llvm-svn: 356441
Summary:
Import type location in case of TypeSpec and TypeSpecWithTemplate.
Without this fix the imported NespedNameSpecifierLoc will have an
invalid begin location.
Reviewers: a.sidorin, shafik, a_sidorin, martong
Reviewed By: a_sidorin
Subscribers: rnkovacs, jdoerfert, dkrupp, martong, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D55358
llvm-svn: 356151
Summary:
Member expressions with explicit template arguments were not imported
correctly: the DeclRefExpr was missing. This patch fixes.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58830
llvm-svn: 355596
Summary:
Redecl chains of function templates are not handled well currently. We
want to handle them similarly to functions, i.e. try to keep the
structure of the original AST as much as possible. The aim is to not
squash a prototype with a definition, rather we create both and put them
in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58494
llvm-svn: 355593
Summary:
Redecl chains of classes and class templates are not handled well
currently. We want to handle them similarly to functions, i.e. try to
keep the structure of the original AST as much as possible. The aim is
to not squash a prototype with a definition, rather we create both and
put them in a redecl chain.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58502
llvm-svn: 355390
