Summary:
When Sema encounters a ObjCMethodDecl definition it declares the implicit parameters for the ObjCMethodDecl.
When importing such a method with the ASTImporter we need to do the same for the imported method
otherwise we will crash when generating code (where CodeGen expects that this was called by Sema).
Note I had to implement Objective-C[++] support in Language.cpp as this is the first test for Objective-C and this
would otherwise just hit this 'not implemented' assert when running the unit test.
Reviewers: martong, a.sidorin, shafik
Reviewed By: martong
Subscribers: rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D71112
Summary:
In this patch we provide additional and comprehensive tests for the ODR
handling strategies. This is the continuation of
https://reviews.llvm.org/D59692.
Reviewers: shafik, a_sidorin, balazske, a.sidorin
Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66951
llvm-svn: 372564
Summary:
Correct order of fields and indirect fields in imported RecordDecl
is needed for correct work of record layout calculations.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66866
llvm-svn: 370621
Summary:
Consider this code:
```
void f() {
auto L0 = [](){};
auto L1 = [](){};
}
```
First we import `L0` then `L1`. Currently we end up having only one
CXXRecordDecl for the two different lambdas. And that is a problem if
the body of their op() is different. This happens because when we import
`L1` then lookup finds the existing `L0` and since they are structurally
equivalent we just map the imported L0 to be the counterpart of L1.
We have the same problem in this case:
```
template <typename F0, typename F1>
void f(F0 L0 = [](){}, F1 L1 = [](){}) {}
```
In StructuralEquivalenceContext we could distinquish lambdas only by
their source location in these cases. But we the lambdas are actually
structrually equivalent they differn only by the source location.
Thus, the solution is to disable lookup completely if the decl in
the "from" context is a lambda.
However, that could have other problems: what if the lambda is defined
in a header file and included in several TUs? I think we'd have as many
duplicates as many includes we have. I think we could live with that,
because the lambda classes are TU local anyway, we cannot just access
them from another TU.
Reviewers: a_sidorin, a.sidorin, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66348
llvm-svn: 370461
Summary:
If importing overridden methods fails for a method it can be seen
incorrectly as non-virtual. To avoid this inconsistency the method
is marked with import error to avoid later use of it.
Reviewers: martong, a.sidorin, shafik, a_sidorin
Reviewed By: martong, shafik
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D66933
llvm-svn: 370457
There are numorous flaws about the name conflict handling, this patch
attempts fixes them. Changes in details:
* HandleNameConflict return with a false DeclarationName
Hitherto we effectively never returned with a NameConflict error, even
if the preceding StructuralMatch indicated a conflict.
Because we just simply returned with the parameter `Name` in
HandleNameConflict and that name is almost always `true` when converted to
`bool`.
* Add tests which indicate wrong NameConflict handling
* Add to ConflictingDecls only if decl kind is different
Note, we might not indicate an ODR error when there is an existing record decl
and a enum is imported with same name. But there are other cases. E.g. think
about the case when we import a FunctionTemplateDecl with name f and we found a
simple FunctionDecl with name f. They overload. Or in case of a
ClassTemplateDecl and CXXRecordDecl, the CXXRecordDecl could be the 'templated'
class, so it would be false to report error. So I think we should report a
name conflict error only when we are 100% sure of that. That is why I think it
should be a general pattern to report the error only if the kind is the same.
* Fix failing ctu test with EnumConstandDecl
In ctu-main.c we have the enum class 'A' which brings in the enum
constant 'x' with value 0 into the global namespace.
In ctu-other.c we had the enum class 'B' which brought in the same name
('x') as an enum constant but with a different enum value (42). This is clearly
an ODR violation in the global namespace. The solution was to rename the
second enum constant.
* Introduce ODR handling strategies
Reviewers: a_sidorin, shafik
Differential Revision: https://reviews.llvm.org/D59692
llvm-svn: 370045
Summary:
If there is a friend class template "prototype" (forward declaration)
and later a definition for it in the existing code, this existing
definition may be not found by ASTImporter because it is not linked
to the prototype (under the friend AST node). The problem is fixed by
looping over all found matching decls instead of break after the first
found one.
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/D65269
llvm-svn: 368551
This patch adds the SVE built-in types defined by the Procedure Call
Standard for the Arm Architecture:
https://developer.arm.com/docs/100986/0000
It handles the types in all relevant places that deal with built-in types.
At the moment, some of these places bail out with an error, including:
(1) trying to generate LLVM IR for the types
(2) trying to generate debug info for the types
(3) trying to mangle the types using the Microsoft C++ ABI
(4) trying to @encode the types in Objective C
(1) and (2) are fixed by follow-on patches but (unlike this patch)
they deal mostly with target-specific LLVM details, so seemed like
a logically separate change. There is currently no spec for (3) and
(4), so reporting an error seems like the correct behaviour for now.
The intention is that the types will become sizeless types:
http://lists.llvm.org/pipermail/cfe-dev/2019-June/062523.html
The main purpose of the sizeless type extension is to diagnose
impossible or dangerous uses of the types, such as any that would
require sizeof to have a meaningful defined value.
Until then, the patch sets the alignments of the types to the values
specified in the link above. It also sets the sizes of the types to
zero, which is chosen to be consistently wrong and shouldn't affect
correctly-written code (i.e. code that would compile even with the
sizeless type extension).
The patch adds the common subset of functionality needed to test the
sizeless type extension on the one hand and to provide SVE intrinsic
functions on the other. After this patch, the two pieces of work are
essentially independent.
The patch is based on one by Graham Hunter:
https://reviews.llvm.org/D59245
Differential Revision: https://reviews.llvm.org/D62960
llvm-svn: 368413
Summary:
For functions there is a check to not duplicate the declaration if it is in a
record (class). For function templates there was no similar check, if a
template (in the same class) was imported multiple times the
FunctionTemplateDecl was created multiple times with the same templated
FunctionDecl. This can result in problems with the declaration chain.
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/D65203
llvm-svn: 368163
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:
The structural equivalence check reported false eq between lambda classes
with different parameters in their call signature.
The solution is to check the methods for equality too in case of lambda
classes.
Reviewers: a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D64075
llvm-svn: 366332
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:
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:
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
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
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
FileManager constructs a VFS in its constructor if it isn't passed one,
and there's no way to reset it. Make that contract clear by returning a
reference from its accessor.
https://reviews.llvm.org/D59388
llvm-svn: 357038
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:
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
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
This was originally reviewed and approved in
https://reviews.llvm.org/D58292 and submitted as r354832. It was
reverted in r354839 due to failures on the Windows CI builds.
This version fixes the test failures on Windows, which were caused by
differences in template expansion between versions of clang on different
OSes. The version of clang built with MSVC and running on Windows never
expands the template in the C++ test in ImportExpr.ImportChooseExpr in
clang/unittests/AST/ASTImporter.cpp, but the version on Linux does for
the empty arguments and -fms-compatibility.
So, this version of the patch drops the C++ test for
__builtin_choose_expr, since that version was written to catch
regressions of the logic for isConditionTrue() in the AST import code
for ChooseExpr, and those regressions are also caught by
ASTImporterOptionSpecificTestBase.ImportChooseExpr, which does work on
Windows.
Reviewers: shafik, a_sidorin, martong, aaron.ballman, rnk, a.sidorin
Subscribers: cfe-commits, jdoerfert, rnkovacs, aaron.ballman
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58663
llvm-svn: 354916
Summary:
This allows ASTs to be merged when they contain ChooseExpr (the GNU
__builtin_choose_expr construction). This is needed, for example, for
cross-CTU analysis of C code that makes use of __builtin_choose_expr.
The node is already supported in the AST, but it didn't have a matcher
in ASTMatchers. So, this change adds the matcher and adds support to
ASTImporter.
Reviewers: shafik, a_sidorin, martong, aaron.ballman
Subscribers: aaron.ballman, rnkovacs, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D58292
llvm-svn: 354832
Summary:
This patch unifies all those tests which check the correctness of the
redecl chains. Previously we had several structurally very similar test
cases for each language construct (class, function, variable, function
template, ...).
We still use value-parameterized tests for the different AST
compatibility switches (-fdelayed-template-parsing, -fms-compatibility).
Gtest makes it possible to have either value-parameterized or
type-parameterized fixtures. However, we cannot have both value- and
type-parameterized test fixtures. So we use a value-parameterized test
fixture in the gtest sense. We intend to mimic gtest's type-parameters
via the type template parameter. We manually instantiate the different
tests with the each types.
After this patch I am planning to put the "generic redecl chain" related
tests into their own separate test file (in another patch).
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D57236
llvm-svn: 354259
Summary:
Previously only the fields were imported. Now every Decl is imported.
This way the destructor decl is not missing after import.
Patch by balazske (Balázs Kéri)
Reviewers: a.sidorin, shafik
Reviewed By: shafik
Subscribers: balazske, cfe-commits, Szelethus, martong, dkrupp
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57740
llvm-svn: 354120
Summary:
During import of a global variable with external visibility the lookup
will find variables (with the same name) but with static visibility.
Clearly, we cannot put them into the same redecl chain. The same is
true in case of functions. In this fix we filter the lookup results and
consider only those which have the same visibility as the decl we
currently import.
We consider two decls in two anonymous namsepaces to have the same
visibility only if they are imported from the very same translation
unit.
Reviewers: a_sidorin, shafik, a.sidorin
Reviewed By: shafik
Subscribers: jdoerfert, balazske, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57232
llvm-svn: 354027
Summary:
We add a new test to show that redecl chains are not handled properly
amongst namespaces. We cannot pass this test now, so this is disabled.
Subsequent patches will make this test pass.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57901
llvm-svn: 353684
Summary:
This is to check that operators are handled properly in
`ASTImporterSpecificLookup`. Note, this lookup table is not used in LLDB, only
in CTU.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57905
llvm-svn: 353505
Summary:
Currently `TestImportBase` is derived from `ParameterizedTestsFixture`
which explicitly states that the gtest parameter can be only an
`ArgVector`. This is a limitation when we want to create tests which may
have different parameters.
E.g. we would like to create tests where we can combine different test
parameters. So, for example we'd like gtest to be able to provide
parameters of `<std::tuple<ArgVector, const char *>` instead of a simple
`ArgVector`.
Reviewers: a_sidorin, shafik, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Differential Revision: https://reviews.llvm.org/D57322
llvm-svn: 353425
Summary:
When importing classes we may add a CXXMethodDecl more than once to a CXXRecordDecl when handling overrides. This patch will fix the cases we currently know about and handle the case where we are only dealing with declarations.
Differential Revision: https://reviews.llvm.org/D56936
llvm-svn: 352436
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
There are certain cases when normal C/C++ lookup (localUncachedLookup)
does not find AST nodes. E.g.:
Example 1:
template <class T>
struct X {
friend void foo(); // this is never found in the DC of the TU.
};
Example 2:
// The fwd decl to Foo is not found in the lookupPtr of the DC of the
// translation unit decl.
struct A { struct Foo *p; };
In these cases we create a new node instead of returning with the old one.
To fix it we create a new lookup table which holds every node and we are
not interested in any C++ specific visibility considerations.
Simply, we must know if there is an existing Decl in a given DC.
Reviewers: a_sidorin, a.sidorin
Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53708
llvm-svn: 349351
Summary:
The crux of the issue that is being fixed is that lookup could not find
previous decls of a friend class. The solution involves making the
friend declarations visible in their decl context (i.e. adding them to
the lookup table).
Also, we simplify `VisitRecordDecl` greatly.
This fix involves two other repairs (without these the unittests fail):
(1) We could not handle the addition of injected class types properly
when a redecl chain was involved, now this is fixed.
(2) DeclContext::removeDecl failed if the lookup table in Vector form
did not contain the to be removed element. This caused troubles in
ASTImporter::ImportDeclContext. This is also fixed.
Reviewers: a_sidorin, balazske, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53655
llvm-svn: 349349
Summary:
When we already have an incomplete underlying type of a typedef in the
"To" context, and the "From" context has the same typedef, but the
underlying type is complete, then the imported type should be complete.
Fixes an assertion in CTU analysis of Xerces:
Assertion `DD && "queried property of class with no definition"' failed.
This assert is happening in the analyzer engine, because that attempts
to query an underlying type of a typedef, which happens to be
incomplete.
Reviewers: a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53693
llvm-svn: 347648
Summary:
If one definition is currently being defined, we do not compare for
equality and we assume that the decls are equal.
Reviewers: a_sidorin, a.sidorin, shafik
Reviewed By: a_sidorin
Subscribers: gamesh411, shafik, rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53697
llvm-svn: 347564
Summary:
Compound literals, enums, file-scoped arrays, etc. require their
initializers and size specifiers to be constant. Wrap the initializer
expressions in a ConstantExpr so that we can easily check for this later
on.
Reviewers: rsmith, shafik
Reviewed By: rsmith
Subscribers: cfe-commits, jyknight, nickdesaulniers
Differential Revision: https://reviews.llvm.org/D53921
llvm-svn: 346455
Summary:
If one definition is currently being defined, we do not compare for
equality and we assume that the decls are equal.
Reviewers: a_sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits
Differential Revision: https://reviews.llvm.org/D53697
llvm-svn: 345760
There are multiple reasons why field structures can be imported
in wrong order. The simplest is the ability of field initializers
and method bodies to refer fields not in order they are listed in.
Unfortunately, there is no clean solution for that currently
so I'm leaving a FIXME.
Differential Revision: https://reviews.llvm.org/D44100
llvm-svn: 345545
Summary:
The goal of this change is to make the ASTImporter::Import functions return
llvm::Expected instead of the imported type.
As first part the ASTNodeImporter visit functions are updated to return with
llvm::Expected. Various `import` functions are added to ASTNodeImporter to
simplify the code and have a common place for interface towards ASTImporter
(from ASTNodeImporter). There is some temporary code that is needed before
ASTImporter is updated.
Reviewers: a.sidorin, a_sidorin, xazax.hun
Reviewed By: a_sidorin
Subscribers: dkrupp, Szelethus, rnkovacs, martong, jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51633
llvm-svn: 344783
This patch moves the virtual file system form clang to llvm so it can be
used by more projects.
Concretely the patch:
- Moves VirtualFileSystem.{h|cpp} from clang/Basic to llvm/Support.
- Moves the corresponding unit test from clang to llvm.
- Moves the vfs namespace from clang::vfs to llvm::vfs.
- Formats the lines affected by this change, mostly this is the result of
the added llvm namespace.
RFC on the mailing list:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126657.html
Differential revision: https://reviews.llvm.org/D52783
llvm-svn: 344140
Summary:
The init expression of a VarDecl is overwritten in the "To" context if we
import a VarDecl without an init expression (and with a definition). Please
refer to the added tests, especially InitAndDefinitionAreInDifferentTUs. This
patch fixes the malfunction by importing the whole Decl chain similarly as we
did that in case of FunctionDecls. We handle the init expression similarly to
a definition, alas only one init expression will be in the merged ast.
Reviewers: a_sidorin, xazax.hun, r.stahl, a.sidorin
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D51597
llvm-svn: 342384
Summary:
Some `Expr` classes set up default values for the `ExprBits` of `Stmt`. These
default values are then overwritten by the parser sometimes. One example is
`InitListExpr` which sets the value kind to be an rvalue in the ctor. However,
this bit may change after the `InitListExpr` is created. There may be other
expressions similar to `InitListExpr` in this sense, thus the safest solution
is to copy the expression bits.
The lack of copying `ExprBits` causes an assertion in the analyzer engine in a
specific case: Since the value kind is not imported, the analyzer engine
believes that the given InitListExpr is an rvalue, thus it creates a
nonloc::CompoundVal instead of creating memory region (as in case of an lvalue
reference).
Reviewers: a_sidorin, r.stahl, xazax.hun, a.sidorin
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D51533
llvm-svn: 341316
Summary:
Currently there are several issues with the import of class template
specializations. (1) Different TUs may have class template specializations
with the same template arguments, but with different set of instantiated
MethodDecls and FieldDecls. In this patch we provide a fix to merge these
methods and fields. (2) Currently, we search the partial template
specializations in the set of simple specializations and we add partial
specializations as simple specializations. This is bad, this patch fixes it.
Reviewers: a_sidorin, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D50451
llvm-svn: 340402
This related to the code as first checked in in r266292 ([ASTImporter]
Implement some expression-related AST node import., 2016-04-14).
llvm-svn: 339731
Summary:
When importing a friend class template declaration,
this declaration should not be merged with any other existing declaration
for the same type. Otherwise the getFriendDecl of the FriendDecl can point
to an other already referenced declaration, this case causes problems.
Additionally the previous decl of class templates is set at import.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D50516
llvm-svn: 339560
Summary:
At equality check of fields without name the index of fields is compared.
At determining the index of a field all fields of the parent context
should be loaded from external source to find the field at all.
Reviewers: a.sidorin, a_sidorin, r.stahl
Reviewed By: a.sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49796
llvm-svn: 339226
Summary: The previous code which avoided infinite recursion (because of reparsing declarations in function parameter lists) contained SourceRange dependent code which had some problems when parameter types were coming from macros. The new solution is not using macros and therefore much safer. A couple of importer problems are fixed in redis and tmux by this fix. Various unittests are included.
Reviewers: a.sidorin, r.stahl, a_sidorin
Reviewed By: a_sidorin
Subscribers: cfe-commits, dkrupp, balazske, martong
Differential Revision: https://reviews.llvm.org/D49792
Patch by Zoltan Gera!
llvm-svn: 339018
Summary:
D48773 simplified ASTImporter nicely, but it introduced a new error: Unnamed
structs are not imported correctly, if they appear in a recursive context.
This patch provides a fix for structural equivalency.
Reviewers: a.sidorin, a_sidorin, balazske, gerazo
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D49296
llvm-svn: 337267
Summary:
When a function is imported, check if it has a described template.
The name lookup is corrected to find the templated entity in this case.
The described template of the function is imported too.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49235
llvm-svn: 337260
Summary:
When an already existing class is encountered during import,
check if it has implicit methods that are missing in the existing one,
and import these.
The to-be-imported code may use the same class in different way than the
existing (before the import) code. This may result in that there are
implicit methods that are not generated for the existing code.
Reviewers: a.sidorin, a_sidorin
Reviewed By: a_sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D49245
llvm-svn: 337162
Summary:
Importing a function having a struct definition in the parameter list
causes a crash in the importer via infinite recursion. This patch avoids
the crash and reports such functions as not supported. Unit tests make
sure that normal struct definitions inside function bodies work normally
on the other hand and LLDB-like type imports also do.
Reviewers: a.sidorin, martong
Differential Revision: https://reviews.llvm.org/D47946
Patch by Zoltan Gera!
llvm-svn: 336898
Summary:
Generalize the creation of Decl nodes during Import. With this patch we do the
same things after and before a new AST node is created (::Create) The import
logic should be really simple, we create the node, then we mark that as
imported, then we recursively import the parts for that node and then set them
on that node. However, the AST is actually a graph, so we have to handle
circles. If we mark something as imported (`MapImported()`) then we return with
the corresponding `To` decl whenever we want to import that node again, this way
circles are handled. In order to make this algorithm work we must ensure
things, which are handled in the generic CreateDecl<> template:
* There are no `Import()` calls in between any node creation (::Create)
and the `MapImported()` call.
* Before actually creating an AST node (::Create), we must check if
the Node had been imported already, if yes then return with that one.
One very important case for this is connected to templates: we may
start an import both from the templated decl of a template and from
the template itself.
Now, the virtual `Imported` function is called in `ASTImporter::Impor(Decl *)`,
but only once, when the `Decl` is imported. One point of this refactor is to
separate responsibilities. The original `Imported()` had 3 responsibilities:
- notify subclasses when an import happened
- register the decl into `ImportedDecls`
- initialise the Decl (set attributes, etc)
Now all of these are in separate functions:
- `Imported`
- `MapImported`
- `InitializeImportedDecl`
I tried to check all the clients, I executed tests for `ExternalASTMerger.cpp`
and some unittests for lldb.
Reviewers: a.sidorin, balazske, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47632
llvm-svn: 336896
Summary: On constructors that do not take the end source location, it was not imported. Fixes test from D47698 / rC336269.
Reviewers: martong, a.sidorin, balazske, xazax.hun, a_sidorin
Reviewed By: martong, a_sidorin
Subscribers: a_sidorin, rnkovacs, cfe-commits
Differential Revision: https://reviews.llvm.org/D48941
llvm-svn: 336523
Summary:
Currently, anonymous types are merged into the same redecl chain even if they
are structurally inequivalent. This results that global objects are not
imported, if there are at least two global objects with different anonymous
types. This patch provides a fix.
Reviewers: a.sidorin, balazske, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D48773
llvm-svn: 336332
Summary:
When running the ASTTests test, warnings produced by the compiler can be
distracting when looking for test errors. A part of the warnings is removed
by setting extra compiler options.
Reviewers: a.sidorin
Reviewed By: a.sidorin
Subscribers: a_sidorin, martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47459
Patch by Balazs Keri!
llvm-svn: 335959
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske, a_sidorin
Reviewed By: a_sidorin
Subscribers: labath, aprantl, a_sidorin, rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
Re-apply commit rC335480
llvm-svn: 335731
Summary:
With this patch when any `FunctionDecl` of a redeclaration chain is imported
then we bring in the whole declaration chain. This involves functions and
function template specializations. Also friend functions are affected. The
chain is imported as it is in the "from" tu, the order of the redeclarations
are kept. I also changed the lookup logic in order to find friends, but first
making them visible in their declaration context. We may have long
redeclaration chains if all TU contains the same prototype, but our
measurements shows no degradation in time of CTU analysis (Tmux, Xerces,
Bitcoin, Protobuf). Also, as further work we could squash redundant
prototypes, but first ensure that functionality is working properly; then
should we optimize.
This may seem like a huge patch, sorry about that. But, most of the changes are
new tests, changes in the production code is not that much. I also tried to
create a smaller patch which does not affect specializations, but that patch
failed to pass some of the `clang-import-test`s because there we import
function specializations. Also very importantly, we can't just change the
import of `FunctionDecl`s without changing the import of function template
specializations because they are handled as `FunctionDecl`s.
Reviewers: a.sidorin, r.stahl, xazax.hun, balazske
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47532
llvm-svn: 335480
Summary:
In order to avoid build failures on MS, we use -fms-compatibility too in
the tests which use the TestBase. Moved the family of `testImport`
functions under a test fixture class, so we can use parameterized tests.
Refactored `testImport` and `testImportSequence`, because `for` loops over
the different compiler options is no longer needed, that is handeld by
the test framework via parameters from now on.
Reviewers: a.sidorin, r.stahl, xazax.hun
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47367
llvm-svn: 335464
Summary:
Add a new test about importing a partial specialization (of a class). Also,
this patch adds new tests about the templated-described swing, some of these
fail ATM, but subsequent patches will fix them.
Reviewers: a.sidorin, r.stahl, xazax.hun
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47534
llvm-svn: 335455
ASTImporter tests may produce source file related warnings, the diagnostic
client should be in correct state to handle it. Added 'beginSourceFile' to set
the client state.
Patch by: Balázs Kéri
Differential Revision: https://reviews.llvm.org/D47445
llvm-svn: 334804
Summary:
When a CXXRecordDecl under ClassTemplateDecl is imported, check
the templated record decl for similarity instead of the template.
Reviewers: a.sidorin
Reviewed By: a.sidorin
Subscribers: martong, cfe-commits
Differential Revision: https://reviews.llvm.org/D47313
Patch by Balazs Keri!
llvm-svn: 333522
Summary:
ClassTemplateSpecialization is put in the wrong DeclContex if implicitly
instantiated. This patch fixes it.
Reviewers: a.sidorin, r.stahl, xazax.hun
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47058
llvm-svn: 333269
Summary:
This patch add new tests for structural equivalence. For that a new
common header is created which holds the test related language specific
types and functions.
Reviewers: a.sidorin, xazax.hun, szepet
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D46867
llvm-svn: 333166
Summary:
Currently we do not import the implicit CXXRecordDecl of a
ClassTemplateSpecializationDecl. This patch fixes it.
Reviewers: a.sidorin, xazax.hun, r.stahl
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47057
llvm-svn: 333086
Summary:
We fail to import a `ClassTemplateDecl` if the "To" context already
contains a definition and then a forward decl. This is because
`localUncachedLookup` does not find the definition. This is not a
lookup error, the parser behaves differently than assumed in the
importer code. A `DeclContext` contains one DenseMap (`LookupPtr`)
which maps names to lists. The list is a special list `StoredDeclsList`
which is optimized to have one element. During building the initial
AST, the parser first adds the definition to the `DeclContext`. Then
during parsing the second declaration (the forward decl) the parser
again calls `DeclContext::addDecl` but that will not add a new element
to the `StoredDeclsList` rarther it simply overwrites the old element
with the most recent one. This patch fixes the error by finding the
definition in the redecl chain. Added tests for the same issue with
`CXXRecordDecl` and with `ClassTemplateSpecializationDecl`. These tests
pass and they pass because in `VisitRecordDecl` and in
`VisitClassTemplateSpecializationDecl` we already use
`D->getDefinition()` after the lookup.
Reviewers: a.sidorin, xazax.hun, szepet
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D46950
llvm-svn: 333082
Summary:
There is a test which passes since D32947, but it was forgotten to be enabled.
This patch enables that disabled test.
Reviewers: a.sidorin, r.stahl, xazax.hun
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D47069
llvm-svn: 332728
Summary:
Implicit CXXRecordDecl is not added to its DeclContext during import, but in
the original AST it is. This patch fixes this.
Reviewers: xazax.hun, a.sidorin, szepet
Subscribers: rnkovacs, dkrupp, cfe-commits
Differential Revision: https://reviews.llvm.org/D46958
llvm-svn: 332588
During import of a class template, lookup may find a forward
declaration and structural match falsely reports equivalency
between a forward decl and a definition. The result is that
some definitions are not imported if we had imported a forward
decl previously. This patch gives a fix.
Patch by Gabor Marton!
Differential Revision: https://reviews.llvm.org/D46353
llvm-svn: 332338
This is a workaround for the issue in buildASTFromCodeWithArgs()
where a local buffer can be used to store the program text
referred by SourceManager.
FIXME: Fix the root issue in buildASTFromCodeWithArgs().
llvm-svn: 332256
The visit callback implementations for the 3 C++ AST Node added to the ASTImporter.
Differential Revision: https://reviews.llvm.org/D38845
llvm-svn: 331630
This patch introduces the ability to test an arbitrary sequence of imports
between a given set of virtual source files. This should finally allow
us to write simple tests and fix annoying issues inside ASTImporter
that cause failures in CSA CTU. This is done by refactoring
ASTImporterTest functions and introducing `testImportSequence` facility.
As a side effect, `testImport` facility was generalized a bit more. It
should now allow import of non-decl AST nodes; however, there is still no
test using this ability.
As a "test for test", there is also a fix for import anonymous TagDecls
referred by typedef. Before this patch, the setting of typedef for anonymous
structure was delayed; however, this approach misses the corner case if
an enum constant is imported directly. In this patch, typedefs for
anonymous declarations are imported right after the anonymous declaration
is imported, without any delay.
Thanks to Adam Balogh for suggestions included into this patch.
Differential Revision: https://reviews.llvm.org/D44079
llvm-svn: 330704
Add a helper test Fixture, so we can add tests which can check internal
attributes of AST nodes like getPreviousDecl(), isVirtual(), etc.
This enables us to check if a redeclaration chain is correctly built during
import, if the virtual flag is preserved during import, etc. We cannot check
such attributes with the existing testImport.
Also, this fixture makes it possible to import from several "From" contexts.
We also added several test cases here, some of them are disabled.
We plan to pass the disabled tests in other patches.
Patch by Gabor Marton!
Differential Revision: https://reviews.llvm.org/D43967
llvm-svn: 328906
Also, a number of style and bug fixes was done:
* ASTImporterTest: added sanity check for source node
* ExternalASTMerger: better lookup for template specializations
* ASTImporter: don't add templated declarations into DeclContext
* ASTImporter: introduce a helper, ImportTemplateArgumentListInfo getting SourceLocations
* ASTImporter: proper set ParmVarDecls for imported FunctionProtoTypeLoc
Differential Revision: https://reviews.llvm.org/D42301
llvm-svn: 323519
* Also introduces ImportTemplateArgumentListInfo facility (A. Sidorin)
This re-commits r320942 after fixing the behaviour on '-fdelayed-template-parsing'
option and adding additional checks.
Patch by Peter Szecsi!
Differential Revision: https://reviews.llvm.org/D38692
llvm-svn: 321492
* While running ASTImporterTests, we often forget about Windows MSVC
buildbots which enable '-fdelayed-template-parsing' by default.
This leads to AST import errors because templates are not parsed
and corresponding parts of AST are not built so importer cannot import them.
It takes both reviewing time to find such issues and post-commit time
to fix unexpected buildbot failures. To solve this issue, we enable testing
with '-fdelayed-template-parsing' option enabled by default in addition
to testing with default compiler options. This allows us to catch
the problem during development.
Differential Revision: https://reviews.llvm.org/D41444
llvm-svn: 321285
Originally, we weren't able to match on Type nodes themselves (only QualType),
so the hasDeclaration matcher was initially written to give what we thought are
reasonable results for QualType matches.
When we chagned the matchers to allow matching on Type nodes, it turned out
that the hasDeclaration matcher was by chance written templated enough to now
allow hasDeclaration to also match on (some) Type nodes.
This patch change the hasDeclaration matcher to:
a) work the same on Type and QualType nodes,
b) be completely explicit about what nodes we can match instead of just allowing
anything with a getDecl() to match,
c) explicitly control desugaring only one level in very specific instances.
d) adds hasSpecializedTemplate and tagType matchers to allow migrating
existing use cases that now need more explicit matchers
Note: This patch breaks clang-tools-extra. The corresponding patch there
is approved and will land in a subsequent patch.
Differential Revision: https://reviews.llvm.org/D27104
llvm-svn: 309809
Raphael Isemann