maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/unittests/AST/ASTImporterTest.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

5939 lines
206 KiB
C++
Raw Normal View History

[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
//===- unittest/AST/ASTImporterTest.cpp - AST node import test ------------===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
//
//===----------------------------------------------------------------------===//
//
// Tests for the correct import of AST nodes from one AST context to another.
//
//===----------------------------------------------------------------------===//
[ASTImporter] Support functions with placeholder return types ... Summary: Support functions with placeholder return types even in cases when the type is declared in the body of the function. Example: auto f() { struct X{}; return X(); } Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70819
2019-12-13 00:13:35 +08:00
#include "clang/ASTMatchers/ASTMatchers.h"
[ASTImporter] Separate unittest files Summary: Move generic redecl chain tests and visibility tests into their own separate test files. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61786 llvm-svn: 360572
2019-05-13 18:06:25 +08:00
#include "llvm/ADT/StringMap.h"
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
#include "llvm/Support/SmallVectorMemoryBuffer.h"
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
#include "clang/AST/DeclContextInternals.h"
[ASTImporter] Support functions with placeholder return types ... Summary: Support functions with placeholder return types even in cases when the type is declared in the body of the function. Example: auto f() { struct X{}; return X(); } Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70819
2019-12-13 00:13:35 +08:00
#include "gtest/gtest.h"
[ASTImporter] Separate unittest files Summary: Move generic redecl chain tests and visibility tests into their own separate test files. Reviewers: a_sidorin, a.sidorin, shafik Subscribers: mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61786 llvm-svn: 360572
2019-05-13 18:06:25 +08:00
#include "ASTImporterFixtures.h"
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
namespace clang {
namespace ast_matchers {
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
using internal::Matcher;
using internal::BindableMatcher;
using llvm::StringMap;
recommit: [ASTImporter] Friend class decl should not be visible in its context Summary: In the past we had to use DeclContext::makeDeclVisibleInContext to make friend declarations available for subsequent lookup calls and this way we could chain (redecl) the structurally equivalent decls. By doing this we created an AST that improperly made declarations visible in some contexts, so the AST was malformed. Since we use the importer specific lookup this is no longer necessary, because with that we can find every previous nodes. Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71020
2019-12-05 00:12:08 +08:00
static const RecordDecl *getRecordDeclOfFriend(FriendDecl *FD) {
QualType Ty = FD->getFriendType()->getType().getCanonicalType();
return cast<RecordType>(Ty)->getDecl();
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
struct ImportExpr : TestImportBase {};
struct ImportType : TestImportBase {};
struct ImportDecl : TestImportBase {};
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
struct ImportFixedPointExpr : ImportExpr {};
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct CanonicalRedeclChain : ASTImporterOptionSpecificTestBase {};
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
TEST_P(CanonicalRedeclChain, ShouldBeConsequentWithMatchers) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f();", Lang_CXX03);
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Pattern = functionDecl(hasName("f"));
auto *D0 = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
auto Redecls = getCanonicalForwardRedeclChain(D0);
ASSERT_EQ(Redecls.size(), 1u);
EXPECT_EQ(D0, Redecls[0]);
}
TEST_P(CanonicalRedeclChain, ShouldBeConsequentWithMatchers2) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f(); void f(); void f();", Lang_CXX03);
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Pattern = functionDecl(hasName("f"));
auto *D0 = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
auto *D2 = LastDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
FunctionDecl *D1 = D2->getPreviousDecl();
auto Redecls = getCanonicalForwardRedeclChain(D0);
ASSERT_EQ(Redecls.size(), 3u);
EXPECT_EQ(D0, Redecls[0]);
EXPECT_EQ(D1, Redecls[1]);
EXPECT_EQ(D2, Redecls[2]);
}
TEST_P(CanonicalRedeclChain, ShouldBeSameForAllDeclInTheChain) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f(); void f(); void f();", Lang_CXX03);
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Pattern = functionDecl(hasName("f"));
auto *D0 = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
auto *D2 = LastDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
FunctionDecl *D1 = D2->getPreviousDecl();
auto RedeclsD0 = getCanonicalForwardRedeclChain(D0);
auto RedeclsD1 = getCanonicalForwardRedeclChain(D1);
auto RedeclsD2 = getCanonicalForwardRedeclChain(D2);
EXPECT_THAT(RedeclsD0, ::testing::ContainerEq(RedeclsD1));
EXPECT_THAT(RedeclsD1, ::testing::ContainerEq(RedeclsD2));
}
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
namespace {
struct RedirectingImporter : public ASTImporter {
using ASTImporter::ASTImporter;
protected:
llvm::Expected<Decl *> ImportImpl(Decl *FromD) override {
auto *ND = dyn_cast<NamedDecl>(FromD);
if (!ND || ND->getName() != "shouldNotBeImported")
return ASTImporter::ImportImpl(FromD);
for (Decl *D : getToContext().getTranslationUnitDecl()->decls()) {
if (auto *ND = dyn_cast<NamedDecl>(D))
if (ND->getName() == "realDecl") {
RegisterImportedDecl(FromD, ND);
return ND;
}
}
return ASTImporter::ImportImpl(FromD);
}
};
} // namespace
struct RedirectingImporterTest : ASTImporterOptionSpecificTestBase {
RedirectingImporterTest() {
Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
ASTContext &FromContext, FileManager &FromFileManager,
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
bool MinimalImport,
const std::shared_ptr<ASTImporterSharedState> &SharedState) {
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
return new RedirectingImporter(ToContext, ToFileManager, FromContext,
FromFileManager, MinimalImport,
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
SharedState);
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
};
}
};
// Test that an ASTImporter subclass can intercept an import call.
TEST_P(RedirectingImporterTest, InterceptImport) {
Decl *From, *To;
std::tie(From, To) =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getImportedDecl("class shouldNotBeImported {};", Lang_CXX03,
"class realDecl {};", Lang_CXX03, "shouldNotBeImported");
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
auto *Imported = cast<CXXRecordDecl>(To);
EXPECT_EQ(Imported->getQualifiedNameAsString(), "realDecl");
// Make sure our importer prevented the importing of the decl.
auto *ToTU = Imported->getTranslationUnitDecl();
auto Pattern = functionDecl(hasName("shouldNotBeImported"));
unsigned count =
DeclCounterWithPredicate<CXXRecordDecl>().match(ToTU, Pattern);
EXPECT_EQ(0U, count);
}
// Test that when we indirectly import a declaration the custom ASTImporter
// is still intercepting the import.
TEST_P(RedirectingImporterTest, InterceptIndirectImport) {
Decl *From, *To;
std::tie(From, To) =
getImportedDecl("class shouldNotBeImported {};"
"class F { shouldNotBeImported f; };",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "class realDecl {};", Lang_CXX03, "F");
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
// Make sure our ASTImporter prevented the importing of the decl.
auto *ToTU = To->getTranslationUnitDecl();
auto Pattern = functionDecl(hasName("shouldNotBeImported"));
unsigned count =
DeclCounterWithPredicate<CXXRecordDecl>().match(ToTU, Pattern);
EXPECT_EQ(0U, count);
}
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
struct ImportPath : ASTImporterOptionSpecificTestBase {
Decl *FromTU;
FunctionDecl *D0, *D1, *D2;
ImportPath() {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FromTU = getTuDecl("void f(); void f(); void f();", Lang_CXX03);
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
auto Pattern = functionDecl(hasName("f"));
D0 = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
D2 = LastDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
D1 = D2->getPreviousDecl();
}
};
TEST_P(ImportPath, Push) {
ASTImporter::ImportPathTy path;
path.push(D0);
EXPECT_FALSE(path.hasCycleAtBack());
}
TEST_P(ImportPath, SmallCycle) {
ASTImporter::ImportPathTy path;
path.push(D0);
path.push(D0);
EXPECT_TRUE(path.hasCycleAtBack());
path.pop();
EXPECT_FALSE(path.hasCycleAtBack());
path.push(D0);
EXPECT_TRUE(path.hasCycleAtBack());
}
TEST_P(ImportPath, GetSmallCycle) {
ASTImporter::ImportPathTy path;
path.push(D0);
path.push(D0);
EXPECT_TRUE(path.hasCycleAtBack());
std::array<Decl* ,2> Res;
int i = 0;
for (Decl *Di : path.getCycleAtBack()) {
Res[i++] = Di;
}
ASSERT_EQ(i, 2);
EXPECT_EQ(Res[0], D0);
EXPECT_EQ(Res[1], D0);
}
TEST_P(ImportPath, GetCycle) {
ASTImporter::ImportPathTy path;
path.push(D0);
path.push(D1);
path.push(D2);
path.push(D0);
EXPECT_TRUE(path.hasCycleAtBack());
std::array<Decl* ,4> Res;
int i = 0;
for (Decl *Di : path.getCycleAtBack()) {
Res[i++] = Di;
}
ASSERT_EQ(i, 4);
EXPECT_EQ(Res[0], D0);
EXPECT_EQ(Res[1], D2);
EXPECT_EQ(Res[2], D1);
EXPECT_EQ(Res[3], D0);
}
TEST_P(ImportPath, CycleAfterCycle) {
ASTImporter::ImportPathTy path;
path.push(D0);
path.push(D1);
path.push(D0);
path.push(D1);
path.push(D2);
path.push(D0);
EXPECT_TRUE(path.hasCycleAtBack());
std::array<Decl* ,4> Res;
int i = 0;
for (Decl *Di : path.getCycleAtBack()) {
Res[i++] = Di;
}
ASSERT_EQ(i, 4);
EXPECT_EQ(Res[0], D0);
EXPECT_EQ(Res[1], D2);
EXPECT_EQ(Res[2], D1);
EXPECT_EQ(Res[3], D0);
path.pop();
path.pop();
path.pop();
EXPECT_TRUE(path.hasCycleAtBack());
i = 0;
for (Decl *Di : path.getCycleAtBack()) {
Res[i++] = Di;
}
ASSERT_EQ(i, 3);
EXPECT_EQ(Res[0], D0);
EXPECT_EQ(Res[1], D1);
EXPECT_EQ(Res[2], D0);
path.pop();
EXPECT_FALSE(path.hasCycleAtBack());
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportStringLiteral) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)\"foo\"; }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(
stringLiteral(hasType(asString("const char [4]"))))));
testImport("void declToImport() { (void)L\"foo\"; }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(
stringLiteral(hasType(asString("const wchar_t [4]"))))));
testImport("void declToImport() { (void) \"foo\" \"bar\"; }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(
stringLiteral(hasType(asString("const char [7]"))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add support for importing ChooseExpr AST nodes. 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
2019-02-27 03:26:41 +08:00
TEST_P(ImportExpr, ImportChooseExpr) {
MatchVerifier<Decl> Verifier;
// This case tests C code that is not condition-dependent and has a true
// condition.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)__builtin_choose_expr(1, 2, 3); }",
Lang_C99, "", Lang_C99, Verifier,
functionDecl(hasDescendant(chooseExpr())));
[ASTImporter] Add support for importing ChooseExpr AST nodes. 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
2019-02-27 03:26:41 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportGNUNullExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)__null; }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(gnuNullExpr(hasType(isInteger())))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXNullPtrLiteralExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"void declToImport() { (void)nullptr; }",
Lang_CXX11, "", Lang_CXX11, Verifier,
functionDecl(hasDescendant(cxxNullPtrLiteralExpr())));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportFloatinglLiteralExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)1.0; }", Lang_C99, "", Lang_C99,
Verifier,
functionDecl(hasDescendant(
floatLiteral(equals(1.0), hasType(asString("double"))))));
testImport("void declToImport() { (void)1.0e-5f; }", Lang_C99, "", Lang_C99,
Verifier,
functionDecl(hasDescendant(
floatLiteral(equals(1.0e-5f), hasType(asString("float"))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
TEST_P(ImportFixedPointExpr, ImportFixedPointerLiteralExpr) {
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)1.0k; }", Lang_C99, "", Lang_C99,
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
Verifier, functionDecl(hasDescendant(fixedPointLiteral())));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)0.75r; }", Lang_C99, "", Lang_C99,
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
Verifier, functionDecl(hasDescendant(fixedPointLiteral())));
}
Add support for importing imaginary literals Reviewers: a_sidorin, r.stahl, xazax.hun Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D50428 llvm-svn: 339334
2018-08-09 20:18:07 +08:00
TEST_P(ImportExpr, ImportImaginaryLiteralExpr) {
MatchVerifier<Decl> Verifier;
testImport(
"void declToImport() { (void)1.0i; }",
Lang_CXX14, "", Lang_CXX14, Verifier,
functionDecl(hasDescendant(imaginaryLiteral())));
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCompoundLiteralExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() {"
" struct s { int x; long y; unsigned z; }; "
" (void)(struct s){ 42, 0L, 1U }; }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionDecl(hasDescendant(compoundLiteralExpr(
hasType(asString("struct s")),
has(initListExpr(
hasType(asString("struct s")),
has(integerLiteral(equals(42), hasType(asString("int")))),
has(integerLiteral(equals(0), hasType(asString("long")))),
has(integerLiteral(
equals(1), hasType(asString("unsigned int"))))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXThisExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("class declToImport { void f() { (void)this; } };", Lang_CXX03, "",
Lang_CXX03, Verifier,
cxxRecordDecl(hasMethod(hasDescendant(
cxxThisExpr(hasType(asString("class declToImport *")))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportAtomicExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { int *ptr; __atomic_load_n(ptr, 1); }",
Lang_C99, "", Lang_C99, Verifier,
functionDecl(hasDescendant(atomicExpr(
has(ignoringParenImpCasts(
declRefExpr(hasDeclaration(varDecl(hasName("ptr"))),
hasType(asString("int *"))))),
has(integerLiteral(equals(1), hasType(asString("int"))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportLabelDeclAndAddrLabelExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { loop: goto loop; (void)&&loop; }", Lang_C99,
"", Lang_C99, Verifier,
functionDecl(hasDescendant(labelStmt(
hasDeclaration(labelDecl(hasName("loop"))))),
hasDescendant(addrLabelExpr(
hasDeclaration(labelDecl(hasName("loop")))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
AST_MATCHER_P(TemplateDecl, hasTemplateDecl,
internal::Matcher<NamedDecl>, InnerMatcher) {
const NamedDecl *Template = Node.getTemplatedDecl();
return Template && InnerMatcher.matches(*Template, Finder, Builder);
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportParenListExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporterTest] Add mandatory testing with '-fdelayed-template-parsing' * 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
2017-12-22 01:41:06 +08:00
testImport(
Unify and simplify the behavior of the hasDeclaration matcher. 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
2017-08-02 21:04:44 +08:00
"template<typename T> class dummy { void f() { dummy X(*this); } };"
"typedef dummy<int> declToImport;"
"template class dummy<int>;",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, Verifier,
Unify and simplify the behavior of the hasDeclaration matcher. 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
2017-08-02 21:04:44 +08:00
typedefDecl(hasType(templateSpecializationType(
hasDeclaration(classTemplateSpecializationDecl(hasSpecializedTemplate(
classTemplateDecl(hasTemplateDecl(cxxRecordDecl(hasMethod(allOf(
hasName("f"),
hasBody(compoundStmt(has(declStmt(hasSingleDecl(
varDecl(hasInitializer(parenListExpr(has(unaryOperator(
hasOperatorName("*"),
[ASTImporterTest] Add mandatory testing with '-fdelayed-template-parsing' * 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
2017-12-22 01:41:06 +08:00
hasUnaryOperand(cxxThisExpr())))))))))))))))))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportSwitch) {
[ASTImporter] Import SubStmt of CaseStmt Patch by: Rafael Stahl! Differential Revision: https://reviews.llvm.org/D38943 llvm-svn: 316069
2017-10-18 17:25:18 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { int b; switch (b) { case 1: break; } }",
Lang_C99, "", Lang_C99, Verifier,
functionDecl(hasDescendant(
switchStmt(has(compoundStmt(has(caseStmt())))))));
[ASTImporter] Import SubStmt of CaseStmt Patch by: Rafael Stahl! Differential Revision: https://reviews.llvm.org/D38943 llvm-svn: 316069
2017-10-18 17:25:18 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportStmtExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporterTest] Add mandatory testing with '-fdelayed-template-parsing' * 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
2017-12-22 01:41:06 +08:00
testImport(
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
"void declToImport() { int b; int a = b ?: 1; int C = ({int X=4; X;}); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "", Lang_C99, Verifier,
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
traverse(ast_type_traits::TK_AsIs,
functionDecl(hasDescendant(varDecl(
hasName("C"), hasType(asString("int")),
hasInitializer(stmtExpr(
hasAnySubstatement(declStmt(hasSingleDecl(varDecl(
hasName("X"), hasType(asString("int")),
hasInitializer(integerLiteral(equals(4))))))),
hasDescendant(implicitCastExpr()))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportConditionalOperator) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)(true ? 1 : -5); }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(conditionalOperator(
hasCondition(cxxBoolLiteral(equals(true))),
hasTrueExpression(integerLiteral(equals(1))),
hasFalseExpression(unaryOperator(
hasUnaryOperand(integerLiteral(equals(5)))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportBinaryConditionalOperator) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporterTest] Add mandatory testing with '-fdelayed-template-parsing' * 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
2017-12-22 01:41:06 +08:00
testImport(
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
"void declToImport() { (void)(1 ?: -5); }", Lang_CXX03, "", Lang_CXX03,
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
Verifier,
traverse(ast_type_traits::TK_AsIs,
functionDecl(hasDescendant(binaryConditionalOperator(
hasCondition(implicitCastExpr(
hasSourceExpression(opaqueValueExpr(
hasSourceExpression(integerLiteral(equals(1))))),
hasType(booleanType()))),
hasTrueExpression(opaqueValueExpr(
hasSourceExpression(integerLiteral(equals(1))))),
hasFalseExpression(unaryOperator(
hasOperatorName("-"),
hasUnaryOperand(integerLiteral(equals(5))))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportDesignatedInitExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"void declToImport() {"
" struct point { double x; double y; };"
" struct point ptarray[10] = "
"{ [2].y = 1.0, [2].x = 2.0, [0].x = 1.0 }; }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "", Lang_C99, Verifier,
functionDecl(hasDescendant(initListExpr(
has(designatedInitExpr(designatorCountIs(2),
hasDescendant(floatLiteral(equals(1.0))),
hasDescendant(integerLiteral(equals(2))))),
has(designatedInitExpr(designatorCountIs(2),
hasDescendant(floatLiteral(equals(2.0))),
hasDescendant(integerLiteral(equals(2))))),
has(designatedInitExpr(designatorCountIs(2),
hasDescendant(floatLiteral(equals(1.0))),
hasDescendant(integerLiteral(equals(0)))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportPredefinedExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
// __func__ expands as StringLiteral("declToImport")
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport() { (void)__func__; }", Lang_CXX03, "",
Lang_CXX03, Verifier,
functionDecl(hasDescendant(predefinedExpr(
hasType(asString("const char [13]")),
has(stringLiteral(hasType(asString("const char [13]"))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportInitListExpr) {
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporterTest] Add mandatory testing with '-fdelayed-template-parsing' * 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
2017-12-22 01:41:06 +08:00
testImport(
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
"void declToImport() {"
" struct point { double x; double y; };"
" point ptarray[10] = { [2].y = 1.0, [2].x = 2.0,"
" [0].x = 1.0 }; }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, Verifier,
functionDecl(hasDescendant(initListExpr(
has(cxxConstructExpr(requiresZeroInitialization())),
has(initListExpr(
hasType(asString("struct point")), has(floatLiteral(equals(1.0))),
has(implicitValueInitExpr(hasType(asString("double")))))),
has(initListExpr(hasType(asString("struct point")),
has(floatLiteral(equals(2.0))),
has(floatLiteral(equals(1.0)))))))));
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
}
[ASTImporter] Implement some expression-related AST node import (part 2) * Some code cleanup * Add tests not present in http://reviews.llvm.org/D14286 * Integrate a test suite from Serge Pavlov (http://reviews.llvm.org/D14224) * ArrayTypeTraitExpr: serialize sub-expression to avoid keeping it undefined * Implement import of some nodes: - ArrayTypeTraitExpr - ExpressionTraitExpr - OpaqueValueExpr - ArraySubscriptExpr - ExplicitCastExpr - ImplicitValueInitExpr - OffsetOfExpr - CXXThisExpr - CXXThrowExpr - CXXNoexceptExpr - CXXDefaultArgExpr - CXXScalarValueInitExpr - CXXBindTemporaryExpr - CXXTemporaryObjectExpr - MaterializeTemporaryExpr - ExprWithCleanups - StaticAssertDecl - FriendDecl - DecayedType Differential Revision: https://reviews.llvm.org/D14326 llvm-svn: 282572
2016-09-28 18:16:56 +08:00
const internal::VariadicDynCastAllOfMatcher<Expr, VAArgExpr> vaArgExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportVAArgExpr) {
[ASTImporter] Implement some expression-related AST node import (part 2) * Some code cleanup * Add tests not present in http://reviews.llvm.org/D14286 * Integrate a test suite from Serge Pavlov (http://reviews.llvm.org/D14224) * ArrayTypeTraitExpr: serialize sub-expression to avoid keeping it undefined * Implement import of some nodes: - ArrayTypeTraitExpr - ExpressionTraitExpr - OpaqueValueExpr - ArraySubscriptExpr - ExplicitCastExpr - ImplicitValueInitExpr - OffsetOfExpr - CXXThisExpr - CXXThrowExpr - CXXNoexceptExpr - CXXDefaultArgExpr - CXXScalarValueInitExpr - CXXBindTemporaryExpr - CXXTemporaryObjectExpr - MaterializeTemporaryExpr - ExprWithCleanups - StaticAssertDecl - FriendDecl - DecayedType Differential Revision: https://reviews.llvm.org/D14326 llvm-svn: 282572
2016-09-28 18:16:56 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("void declToImport(__builtin_va_list list, ...) {"
" (void)__builtin_va_arg(list, int); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionDecl(hasDescendant(
cStyleCastExpr(hasSourceExpression(vaArgExpr())))));
[ASTImporter] Implement some expression-related AST node import (part 2) * Some code cleanup * Add tests not present in http://reviews.llvm.org/D14286 * Integrate a test suite from Serge Pavlov (http://reviews.llvm.org/D14224) * ArrayTypeTraitExpr: serialize sub-expression to avoid keeping it undefined * Implement import of some nodes: - ArrayTypeTraitExpr - ExpressionTraitExpr - OpaqueValueExpr - ArraySubscriptExpr - ExplicitCastExpr - ImplicitValueInitExpr - OffsetOfExpr - CXXThisExpr - CXXThrowExpr - CXXNoexceptExpr - CXXDefaultArgExpr - CXXScalarValueInitExpr - CXXBindTemporaryExpr - CXXTemporaryObjectExpr - MaterializeTemporaryExpr - ExprWithCleanups - StaticAssertDecl - FriendDecl - DecayedType Differential Revision: https://reviews.llvm.org/D14326 llvm-svn: 282572
2016-09-28 18:16:56 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, CXXTemporaryObjectExpr) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"struct C {};"
"void declToImport() { C c = C(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, Verifier,
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
traverse(ast_type_traits::TK_AsIs,
functionDecl(hasDescendant(exprWithCleanups(has(cxxConstructExpr(
has(materializeTemporaryExpr(has(implicitCastExpr(
has(cxxTemporaryObjectExpr()))))))))))));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
}
[ASTImporter] Implement some expression-related AST node import (part 2) * Some code cleanup * Add tests not present in http://reviews.llvm.org/D14286 * Integrate a test suite from Serge Pavlov (http://reviews.llvm.org/D14224) * ArrayTypeTraitExpr: serialize sub-expression to avoid keeping it undefined * Implement import of some nodes: - ArrayTypeTraitExpr - ExpressionTraitExpr - OpaqueValueExpr - ArraySubscriptExpr - ExplicitCastExpr - ImplicitValueInitExpr - OffsetOfExpr - CXXThisExpr - CXXThrowExpr - CXXNoexceptExpr - CXXDefaultArgExpr - CXXScalarValueInitExpr - CXXBindTemporaryExpr - CXXTemporaryObjectExpr - MaterializeTemporaryExpr - ExprWithCleanups - StaticAssertDecl - FriendDecl - DecayedType Differential Revision: https://reviews.llvm.org/D14326 llvm-svn: 282572
2016-09-28 18:16:56 +08:00
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportType, ImportAtomicType) {
[ASTImporter] Added ability to import AtomicType nodes Patch by: Kareem Khazem Differential Revision: https://reviews.llvm.org/D26328 llvm-svn: 287763
2016-11-23 23:24:23 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"void declToImport() { typedef _Atomic(int) a_int; }",
Lang_CXX11, "", Lang_CXX11, Verifier,
functionDecl(hasDescendant(typedefDecl(has(atomicType())))));
[ASTImporter] Added ability to import AtomicType nodes Patch by: Kareem Khazem Differential Revision: https://reviews.llvm.org/D26328 llvm-svn: 287763
2016-11-23 23:24:23 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportFunctionTemplateDecl) {
[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr * 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
2017-12-28 01:04:42 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template <typename T> void declToImport() { };", Lang_CXX03, "",
Lang_CXX03, Verifier, functionTemplateDecl());
[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr * 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
2017-12-28 01:04:42 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXDependentScopeMemberExpr) {
[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr * 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
2017-12-28 01:04:42 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template <typename T> struct C { T t; };"
"template <typename T> void declToImport() {"
" C<T> d;"
" (void)d.t;"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasDescendant(
cStyleCastExpr(has(cxxDependentScopeMemberExpr())))));
testImport("template <typename T> struct C { T t; };"
"template <typename T> void declToImport() {"
" C<T> d;"
" (void)(&d)->t;"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasDescendant(
cStyleCastExpr(has(cxxDependentScopeMemberExpr())))));
[ASTImporter] Support importing FunctionTemplateDecl and CXXDependentScopeMemberExpr * 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
2017-12-28 01:04:42 +08:00
}
[ASTImporter] Added ability to import AtomicType nodes Patch by: Kareem Khazem Differential Revision: https://reviews.llvm.org/D26328 llvm-svn: 287763
2016-11-23 23:24:23 +08:00
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportType, ImportTypeAliasTemplate) {
[ASTImporter] TypeAliasTemplate and PackExpansion importing capability Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
2017-11-14 19:30:38 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Fix lexical DC for templated decls; support VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
2018-02-14 19:18:00 +08:00
testImport(
"template <int K>"
"struct dummy { static const int i = K; };"
"template <int K> using dummy2 = dummy<K>;"
"int declToImport() { return dummy2<3>::i; }",
Lang_CXX11, "", Lang_CXX11, Verifier,
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
traverse(ast_type_traits::TK_AsIs,
functionDecl(hasDescendant(implicitCastExpr(has(declRefExpr()))),
unless(hasAncestor(
translationUnitDecl(has(typeAliasDecl())))))));
[ASTImporter] Fix lexical DC for templated decls; support VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
2018-02-14 19:18:00 +08:00
}
const internal::VariadicDynCastAllOfMatcher<Decl, VarTemplateSpecializationDecl>
varTemplateSpecializationDecl;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportVarTemplate) {
[ASTImporter] Fix lexical DC for templated decls; support VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
2018-02-14 19:18:00 +08:00
MatchVerifier<Decl> Verifier;
testImport(
"template <typename T>"
"T pi = T(3.1415926535897932385L);"
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
"void declToImport() { (void)pi<int>; }",
Lang_CXX14, "", Lang_CXX14, Verifier,
[ASTImporter] Fix lexical DC for templated decls; support VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
2018-02-14 19:18:00 +08:00
functionDecl(
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
hasDescendant(declRefExpr(to(varTemplateSpecializationDecl()))),
[ASTImporter] Fix lexical DC for templated decls; support VarTemplatePartialSpecDecl Also minor refactoring in related functions was done. Differential Revision: https://reviews.llvm.org/D43012 llvm-svn: 325116
2018-02-14 19:18:00 +08:00
unless(hasAncestor(translationUnitDecl(has(varDecl(
hasName("pi"), unless(varTemplateSpecializationDecl()))))))));
[ASTImporter] TypeAliasTemplate and PackExpansion importing capability Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
2017-11-14 19:30:38 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportType, ImportPackExpansion) {
[ASTImporter] TypeAliasTemplate and PackExpansion importing capability Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
2017-11-14 19:30:38 +08:00
MatchVerifier<Decl> Verifier;
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
testImport("template <typename... Args>"
"struct dummy {"
" dummy(Args... args) {}"
" static const int i = 4;"
"};"
"int declToImport() { return dummy<int>::i; }",
Lang_CXX11, "", Lang_CXX11, Verifier,
traverse(ast_type_traits::TK_AsIs,
functionDecl(hasDescendant(returnStmt(
has(implicitCastExpr(has(declRefExpr()))))))));
[ASTImporter] TypeAliasTemplate and PackExpansion importing capability Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
2017-11-14 19:30:38 +08:00
}
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
const internal::VariadicDynCastAllOfMatcher<Type,
DependentTemplateSpecializationType>
dependentTemplateSpecializationType;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportType, ImportDependentTemplateSpecialization) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template<typename T>"
"struct A;"
"template<typename T>"
"struct declToImport {"
" typename A<T>::template B<T> a;"
"};",
Lang_CXX03, "", Lang_CXX03, Verifier,
classTemplateDecl(has(cxxRecordDecl(has(
fieldDecl(hasType(dependentTemplateSpecializationType())))))));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
}
const internal::VariadicDynCastAllOfMatcher<Stmt, SizeOfPackExpr>
sizeOfPackExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportSizeOfPackExpr) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"template <typename... Ts>"
"void declToImport() {"
" const int i = sizeof...(Ts);"
"};"
"void g() { declToImport<int>(); }",
Lang_CXX11, "", Lang_CXX11, Verifier,
functionTemplateDecl(hasDescendant(sizeOfPackExpr())));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
testImport(
"template <typename... Ts>"
"using X = int[sizeof...(Ts)];"
"template <typename... Us>"
"struct Y {"
" X<Us..., int, double, int, Us...> f;"
"};"
"Y<float, int> declToImport;",
Lang_CXX11, "", Lang_CXX11, Verifier,
varDecl(hasType(classTemplateSpecializationDecl(has(fieldDecl(hasType(
hasUnqualifiedDesugaredType(constantArrayType(hasSize(7))))))))));
}
[ASTImporter] Support TypeTraitExpr Patch by Takafumi Kubota! Differential Revision: https://reviews.llvm.org/D39722 llvm-svn: 318998
2017-11-27 01:04:06 +08:00
/// \brief Matches __builtin_types_compatible_p:
/// GNU extension to check equivalent types
/// Given
/// \code
/// __builtin_types_compatible_p(int, int)
/// \endcode
// will generate TypeTraitExpr <...> 'int'
const internal::VariadicDynCastAllOfMatcher<Stmt, TypeTraitExpr> typeTraitExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportTypeTraitExpr) {
[ASTImporter] Support TypeTraitExpr Patch by Takafumi Kubota! Differential Revision: https://reviews.llvm.org/D39722 llvm-svn: 318998
2017-11-27 01:04:06 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"void declToImport() { "
" (void)__builtin_types_compatible_p(int, int);"
"}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "", Lang_C99, Verifier,
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
functionDecl(hasDescendant(typeTraitExpr(hasType(asString("int"))))));
[ASTImporter] Support TypeTraitExpr Patch by Takafumi Kubota! Differential Revision: https://reviews.llvm.org/D39722 llvm-svn: 318998
2017-11-27 01:04:06 +08:00
}
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
const internal::VariadicDynCastAllOfMatcher<Stmt, CXXTypeidExpr> cxxTypeidExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXTypeidExpr) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
testImport(
"namespace std { class type_info {}; }"
"void declToImport() {"
" int x;"
" auto a = typeid(int); auto b = typeid(x);"
"}",
Lang_CXX11, "", Lang_CXX11, Verifier,
Set traversal explicitly where needed in tests Reviewers: aaron.ballman, shafik Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D72531
2019-11-12 21:29:40 +08:00
traverse(
ast_type_traits::TK_AsIs,
functionDecl(
hasDescendant(varDecl(hasName("a"), hasInitializer(hasDescendant(
cxxTypeidExpr())))),
hasDescendant(varDecl(hasName("b"), hasInitializer(hasDescendant(
cxxTypeidExpr())))))));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportTypeTraitExprValDep) {
[ASTImporter] Support TypeTraitExpr Patch by Takafumi Kubota! Differential Revision: https://reviews.llvm.org/D39722 llvm-svn: 318998
2017-11-27 01:04:06 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"template<typename T> struct declToImport {"
" void m() { (void)__is_pod(T); }"
"};"
"void f() { declToImport<int>().m(); }",
Lang_CXX11, "", Lang_CXX11, Verifier,
classTemplateDecl(has(cxxRecordDecl(has(
functionDecl(hasDescendant(
typeTraitExpr(hasType(booleanType())))))))));
[ASTImporter] Support TypeTraitExpr Patch by Takafumi Kubota! Differential Revision: https://reviews.llvm.org/D39722 llvm-svn: 318998
2017-11-27 01:04:06 +08:00
}
[ASTImporter] TypeAliasTemplate and PackExpansion importing capability Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
2017-11-14 19:30:38 +08:00
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
TEST_P(ImportDecl, ImportRecordDeclInFunc) {
MatchVerifier<Decl> Verifier;
testImport("int declToImport() { "
" struct data_t {int a;int b;};"
" struct data_t d;"
" return 0;"
"}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "", Lang_C99, Verifier,
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
functionDecl(hasBody(compoundStmt(
has(declStmt(hasSingleDecl(varDecl(hasName("d")))))))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordTypeInFunc) {
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
Decl *FromTU = getTuDecl("int declToImport() { "
" struct data_t {int a;int b;};"
" struct data_t d;"
" return 0;"
"}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "input.c");
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
auto *FromVar =
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
FirstDeclMatcher<VarDecl>().match(FromTU, varDecl(hasName("d")));
ASSERT_TRUE(FromVar);
auto ToType =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ImportType(FromVar->getType().getCanonicalType(), FromVar, Lang_C99);
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
EXPECT_FALSE(ToType.isNull());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordDeclInFuncParams) {
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
// This construct is not supported by ASTImporter.
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
Decl *FromTU = getTuDecl(
"int declToImport(struct data_t{int a;int b;} ***d){ return 0; }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "input.c");
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
auto *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("declToImport")));
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
ASSERT_TRUE(From);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *To = Import(From, Lang_C99);
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
EXPECT_EQ(To, nullptr);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportRecordDeclInFuncFromMacro) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("#define NONAME_SIZEOF(type) sizeof(struct{type *dummy;}) \n"
"int declToImport(){ return NONAME_SIZEOF(int); }",
Lang_C99, "input.c");
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
auto *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("declToImport")));
ASSERT_TRUE(From);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *To = Import(From, Lang_C99);
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
ASSERT_TRUE(To);
EXPECT_TRUE(MatchVerifier<FunctionDecl>().match(
To, functionDecl(hasName("declToImport"),
hasDescendant(unaryExprOrTypeTraitExpr()))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportRecordDeclInFuncParamsFromMacro) {
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
// This construct is not supported by ASTImporter.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("#define PAIR_STRUCT(type) struct data_t{type a;type b;} \n"
"int declToImport(PAIR_STRUCT(int) ***d){ return 0; }",
Lang_C99, "input.c");
[ASTmporter] SourceRange-free function parameter checking for declarations 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
2018-08-06 22:38:37 +08:00
auto *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("declToImport")));
ASSERT_TRUE(From);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *To = Import(From, Lang_C99);
[ASTImporter] Fix infinite recursion on function import with struct definition in parameters 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
2018-07-12 19:50:21 +08:00
EXPECT_EQ(To, nullptr);
}
[ASTImporter] Support importing CXXPseudoDestructorExpr Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38843 llvm-svn: 319015
2017-11-27 18:30:00 +08:00
const internal::VariadicDynCastAllOfMatcher<Expr, CXXPseudoDestructorExpr>
cxxPseudoDestructorExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXPseudoDestructorExpr) {
[ASTImporter] Support importing CXXPseudoDestructorExpr Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38843 llvm-svn: 319015
2017-11-27 18:30:00 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"typedef int T;"
"void declToImport(int *p) {"
" T t;"
" p->T::~T();"
"}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, Verifier,
functionDecl(hasDescendant(callExpr(has(cxxPseudoDestructorExpr())))));
[ASTImporter] Support importing CXXPseudoDestructorExpr Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38843 llvm-svn: 319015
2017-11-27 18:30:00 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportUsingDecl) {
[ASTImporter] Add unit tests for UsingDecl and UsingShadowDecl Patch by Kareem Khazem! Differential Revision: https://reviews.llvm.org/D27181 llvm-svn: 319632
2017-12-04 00:04:07 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("namespace foo { int bar; }"
"void declToImport() { using foo::bar; }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionDecl(hasDescendant(usingDecl())));
[ASTImporter] Add unit tests for UsingDecl and UsingShadowDecl Patch by Kareem Khazem! Differential Revision: https://reviews.llvm.org/D27181 llvm-svn: 319632
2017-12-04 00:04:07 +08:00
}
/// \brief Matches shadow declarations introduced into a scope by a
/// (resolved) using declaration.
///
/// Given
/// \code
/// namespace n { int f; }
/// namespace declToImport { using n::f; }
/// \endcode
/// usingShadowDecl()
/// matches \code f \endcode
const internal::VariadicDynCastAllOfMatcher<Decl,
UsingShadowDecl> usingShadowDecl;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportUsingShadowDecl) {
[ASTImporter] Add unit tests for UsingDecl and UsingShadowDecl Patch by Kareem Khazem! Differential Revision: https://reviews.llvm.org/D27181 llvm-svn: 319632
2017-12-04 00:04:07 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("namespace foo { int bar; }"
"namespace declToImport { using foo::bar; }",
Lang_CXX03, "", Lang_CXX03, Verifier,
namespaceDecl(has(usingShadowDecl())));
[ASTImporter] Add unit tests for UsingDecl and UsingShadowDecl Patch by Kareem Khazem! Differential Revision: https://reviews.llvm.org/D27181 llvm-svn: 319632
2017-12-04 00:04:07 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportUnresolvedLookupExpr) {
[ASTImporter] Support importing CXXUnresolvedConstructExpr and UnresolvedLookupExpr * Note: This solution is based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp#L7605. Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38694 llvm-svn: 322091
2018-01-10 00:40:40 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template<typename T> int foo();"
"template <typename T> void declToImport() {"
" (void)::foo<T>;"
" (void)::template foo<T>;"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasDescendant(unresolvedLookupExpr())));
[ASTImporter] Support importing CXXUnresolvedConstructExpr and UnresolvedLookupExpr * Note: This solution is based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp#L7605. Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38694 llvm-svn: 322091
2018-01-10 00:40:40 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, ImportCXXUnresolvedConstructExpr) {
[ASTImporter] Support importing CXXUnresolvedConstructExpr and UnresolvedLookupExpr * Note: This solution is based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp#L7605. Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38694 llvm-svn: 322091
2018-01-10 00:40:40 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template <typename T> struct C { T t; };"
"template <typename T> void declToImport() {"
" C<T> d;"
" d.t = T();"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasDescendant(
binaryOperator(has(cxxUnresolvedConstructExpr())))));
testImport("template <typename T> struct C { T t; };"
"template <typename T> void declToImport() {"
" C<T> d;"
" (&d)->t = T();"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasDescendant(
binaryOperator(has(cxxUnresolvedConstructExpr())))));
[ASTImporter] Support importing CXXUnresolvedConstructExpr and UnresolvedLookupExpr * Note: This solution is based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp#L7605. Patch by Peter Szecsi! Differential Revision: https://reviews.llvm.org/D38694 llvm-svn: 322091
2018-01-10 00:40:40 +08:00
}
[ASTImporter] Support LambdaExprs and improve template support 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
2018-01-26 19:36:54 +08:00
/// Check that function "declToImport()" (which is the templated function
/// for corresponding FunctionTemplateDecl) is not added into DeclContext.
/// Same for class template declarations.
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportTemplatedDeclForTemplate) {
[ASTImporter] Support LambdaExprs and improve template support 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
2018-01-26 19:36:54 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template <typename T> void declToImport() { T a = 1; }"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
functionTemplateDecl(hasAncestor(translationUnitDecl(
unless(has(functionDecl(hasName("declToImport"))))))));
testImport("template <typename T> struct declToImport { T t; };"
"void instantiate() { declToImport<int>(); }",
Lang_CXX03, "", Lang_CXX03, Verifier,
classTemplateDecl(hasAncestor(translationUnitDecl(
unless(has(cxxRecordDecl(hasName("declToImport"))))))));
[ASTImporter] Support LambdaExprs and improve template support 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
2018-01-26 19:36:54 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportClassTemplatePartialSpecialization) {
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
MatchVerifier<Decl> Verifier;
auto Code =
R"s(
struct declToImport {
template <typename T0> struct X;
template <typename T0> struct X<T0 *> {};
};
)s";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport(Code, Lang_CXX03, "", Lang_CXX03, Verifier,
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
recordDecl(has(classTemplateDecl()),
has(classTemplateSpecializationDecl())));
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, CXXOperatorCallExpr) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
testImport(
"class declToImport {"
" void f() { *this = declToImport(); }"
"};",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, Verifier,
cxxRecordDecl(has(cxxMethodDecl(hasDescendant(cxxOperatorCallExpr())))));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, DependentSizedArrayType) {
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
MatchVerifier<Decl> Verifier;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
testImport("template<typename T, int Size> class declToImport {"
" T data[Size];"
"};",
Lang_CXX03, "", Lang_CXX03, Verifier,
classTemplateDecl(has(cxxRecordDecl(
has(fieldDecl(hasType(dependentSizedArrayType())))))));
[ASTImporter] Add support to import some AST nodes: * CXXOperatorCallExpr * SizeOfPackExpr * DependentTemplateSpecializationType * DependentSizedArray * CXXTypeidExpr * Fix importing CXXTemporaryObjectExpr Some of the changes are based on https://github.com/haoNoQ/clang/blob/summary-ipa-draft/lib/AST/ASTImporter.cpp Differential Revision: https://reviews.llvm.org/D42335 llvm-svn: 323589
2018-01-28 00:11:45 +08:00
}
[ASTImporter] Fix import of NestedNameSpecifierLoc. 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
2019-03-14 22:20:23 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportBeginLocOfDeclRefExpr) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("class A { public: static int X; }; void f() { (void)A::X; }",
Lang_CXX03);
[ASTImporter] Fix import of NestedNameSpecifierLoc. 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
2019-03-14 22:20:23 +08:00
auto From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
ASSERT_TRUE(From);
ASSERT_TRUE(
cast<CStyleCastExpr>(cast<CompoundStmt>(From->getBody())->body_front())
->getSubExpr()
->getBeginLoc()
.isValid());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *To = Import(From, Lang_CXX03);
[ASTImporter] Fix import of NestedNameSpecifierLoc. 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
2019-03-14 22:20:23 +08:00
ASSERT_TRUE(To);
ASSERT_TRUE(
cast<CStyleCastExpr>(cast<CompoundStmt>(To->getBody())->body_front())
->getSubExpr()
->getBeginLoc()
.isValid());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportOfTemplatedDeclOfClassTemplateDecl) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("template<class X> struct S{};", Lang_CXX03);
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
auto From =
FirstDeclMatcher<ClassTemplateDecl>().match(FromTU, classTemplateDecl());
ASSERT_TRUE(From);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto To = cast<ClassTemplateDecl>(Import(From, Lang_CXX03));
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
ASSERT_TRUE(To);
Decl *ToTemplated = To->getTemplatedDecl();
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTemplated1 = Import(From->getTemplatedDecl(), Lang_CXX03);
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
EXPECT_TRUE(ToTemplated1);
EXPECT_EQ(ToTemplated1, ToTemplated);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportOfTemplatedDeclOfFunctionTemplateDecl) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("template<class X> void f(){}", Lang_CXX03);
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
auto From = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU, functionTemplateDecl());
ASSERT_TRUE(From);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto To = cast<FunctionTemplateDecl>(Import(From, Lang_CXX03));
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
ASSERT_TRUE(To);
Decl *ToTemplated = To->getTemplatedDecl();
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTemplated1 = Import(From->getTemplatedDecl(), Lang_CXX03);
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
EXPECT_TRUE(ToTemplated1);
EXPECT_EQ(ToTemplated1, ToTemplated);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
ImportOfTemplatedDeclShouldImportTheClassTemplateDecl) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("template<class X> struct S{};", Lang_CXX03);
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
auto FromFT =
FirstDeclMatcher<ClassTemplateDecl>().match(FromTU, classTemplateDecl());
ASSERT_TRUE(FromFT);
auto ToTemplated =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
cast<CXXRecordDecl>(Import(FromFT->getTemplatedDecl(), Lang_CXX03));
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
EXPECT_TRUE(ToTemplated);
auto ToTU = ToTemplated->getTranslationUnitDecl();
auto ToFT =
FirstDeclMatcher<ClassTemplateDecl>().match(ToTU, classTemplateDecl());
EXPECT_TRUE(ToFT);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Import described template (if any) of function. 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
2018-07-17 17:52:41 +08:00
ImportOfTemplatedDeclShouldImportTheFunctionTemplateDecl) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("template<class X> void f(){}", Lang_CXX03);
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
auto FromFT = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU, functionTemplateDecl());
ASSERT_TRUE(FromFT);
auto ToTemplated =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
cast<FunctionDecl>(Import(FromFT->getTemplatedDecl(), Lang_CXX03));
[ASTImporter] Add new tests about templated-described swing 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
2018-06-25 19:38:43 +08:00
EXPECT_TRUE(ToTemplated);
auto ToTU = ToTemplated->getTranslationUnitDecl();
auto ToFT = FirstDeclMatcher<FunctionTemplateDecl>().match(
ToTU, functionTemplateDecl());
EXPECT_TRUE(ToFT);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportCorrectTemplatedDecl) {
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
auto Code =
R"(
namespace x {
template<class X> struct S1{};
template<class X> struct S2{};
template<class X> struct S3{};
}
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
auto FromNs =
FirstDeclMatcher<NamespaceDecl>().match(FromTU, namespaceDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto ToNs = cast<NamespaceDecl>(Import(FromNs, Lang_CXX03));
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
ASSERT_TRUE(ToNs);
auto From =
FirstDeclMatcher<ClassTemplateDecl>().match(FromTU,
classTemplateDecl(
hasName("S2")));
auto To =
FirstDeclMatcher<ClassTemplateDecl>().match(ToNs,
classTemplateDecl(
hasName("S2")));
ASSERT_TRUE(From);
ASSERT_TRUE(To);
auto ToTemplated = To->getTemplatedDecl();
auto ToTemplated1 =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
cast<CXXRecordDecl>(Import(From->getTemplatedDecl(), Lang_CXX03));
[ASTImporter] Corrected lookup at import of templated record decl 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
2018-05-30 17:19:26 +08:00
EXPECT_TRUE(ToTemplated1);
ASSERT_EQ(ToTemplated1, ToTemplated);
}
[ASTImporter] Add support for importing ChooseExpr AST nodes. 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
2019-02-27 03:26:41 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportChooseExpr) {
// This tests the import of isConditionTrue directly to make sure the importer
// gets it right.
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
"void declToImport() { (void)__builtin_choose_expr(1, 0, 1); }", Lang_C99,
"", Lang_C99);
[ASTImporter] Add support for importing ChooseExpr AST nodes. 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
2019-02-27 03:26:41 +08:00
auto ToResults = match(chooseExpr().bind("choose"), To->getASTContext());
auto FromResults = match(chooseExpr().bind("choose"), From->getASTContext());
const ChooseExpr *FromChooseExpr =
selectFirst<ChooseExpr>("choose", FromResults);
ASSERT_TRUE(FromChooseExpr);
const ChooseExpr *ToChooseExpr = selectFirst<ChooseExpr>("choose", ToResults);
ASSERT_TRUE(ToChooseExpr);
EXPECT_EQ(FromChooseExpr->isConditionTrue(), ToChooseExpr->isConditionTrue());
EXPECT_EQ(FromChooseExpr->isConditionDependent(),
ToChooseExpr->isConditionDependent());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportFunctionWithBackReferringParameter) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
template <typename T> struct X {};
void declToImport(int y, X<int> &x) {}
template <> struct X<int> {
void g() {
X<int> x;
declToImport(0, x);
}
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
MatchVerifier<Decl> Verifier;
auto Matcher = functionDecl(hasName("declToImport"),
parameterCountIs(2),
hasParameter(0, hasName("y")),
hasParameter(1, hasName("x")),
hasParameter(1, hasType(asString("X<int> &"))));
ASSERT_TRUE(Verifier.match(From, Matcher));
EXPECT_TRUE(Verifier.match(To, Matcher));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
TUshouldNotContainTemplatedDeclOfFunctionTemplates) {
Decl *From, *To;
std::tie(From, To) =
getImportedDecl("template <typename T> void declToImport() { T a = 1; }"
"void instantiate() { declToImport<int>(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto Check = [](Decl *D) -> bool {
auto TU = D->getTranslationUnitDecl();
for (auto Child : TU->decls()) {
if (auto *FD = dyn_cast<FunctionDecl>(Child)) {
if (FD->getNameAsString() == "declToImport") {
GTEST_NONFATAL_FAILURE_(
"TU should not contain any FunctionDecl with name declToImport");
return false;
}
}
}
return true;
};
ASSERT_TRUE(Check(From));
EXPECT_TRUE(Check(To));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
TUshouldNotContainTemplatedDeclOfClassTemplates) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) =
getImportedDecl("template <typename T> struct declToImport { T t; };"
"void instantiate() { declToImport<int>(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto Check = [](Decl *D) -> bool {
auto TU = D->getTranslationUnitDecl();
for (auto Child : TU->decls()) {
if (auto *RD = dyn_cast<CXXRecordDecl>(Child)) {
if (RD->getNameAsString() == "declToImport") {
GTEST_NONFATAL_FAILURE_(
"TU should not contain any CXXRecordDecl with name declToImport");
return false;
}
}
}
return true;
};
ASSERT_TRUE(Check(From));
EXPECT_TRUE(Check(To));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
TUshouldNotContainTemplatedDeclOfTypeAlias) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) =
getImportedDecl(
"template <typename T> struct X {};"
"template <typename T> using declToImport = X<T>;"
"void instantiate() { declToImport<int> a; }",
Lang_CXX11, "", Lang_CXX11);
auto Check = [](Decl *D) -> bool {
auto TU = D->getTranslationUnitDecl();
for (auto Child : TU->decls()) {
if (auto *AD = dyn_cast<TypeAliasDecl>(Child)) {
if (AD->getNameAsString() == "declToImport") {
GTEST_NONFATAL_FAILURE_(
"TU should not contain any TypeAliasDecl with name declToImport");
return false;
}
}
}
return true;
};
ASSERT_TRUE(Check(From));
EXPECT_TRUE(Check(To));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
TUshouldNotContainClassTemplateSpecializationOfImplicitInstantiation) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
template<class T>
class Base {};
class declToImport : public Base<declToImport> {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
// Check that the ClassTemplateSpecializationDecl is NOT the child of the TU.
auto Pattern =
translationUnitDecl(unless(has(classTemplateSpecializationDecl())));
ASSERT_TRUE(
MatchVerifier<Decl>{}.match(From->getTranslationUnitDecl(), Pattern));
EXPECT_TRUE(
MatchVerifier<Decl>{}.match(To->getTranslationUnitDecl(), Pattern));
// Check that the ClassTemplateSpecializationDecl is the child of the
// ClassTemplateDecl.
Pattern = translationUnitDecl(has(classTemplateDecl(
hasName("Base"), has(classTemplateSpecializationDecl()))));
ASSERT_TRUE(
MatchVerifier<Decl>{}.match(From->getTranslationUnitDecl(), Pattern));
EXPECT_TRUE(
MatchVerifier<Decl>{}.match(To->getTranslationUnitDecl(), Pattern));
}
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
AST_MATCHER_P(RecordDecl, hasFieldOrder, std::vector<StringRef>, Order) {
size_t Index = 0;
[ASTImporter] At import of records re-order indirect fields too. 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
2019-09-02 15:17:01 +08:00
for (Decl *D : Node.decls()) {
if (isa<FieldDecl>(D) || isa<IndirectFieldDecl>(D)) {
auto *ND = cast<NamedDecl>(D);
if (Index == Order.size())
return false;
if (ND->getName() != Order[Index])
return false;
++Index;
}
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
}
return Index == Order.size();
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
TUshouldContainClassTemplateSpecializationOfExplicitInstantiation) {
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
namespace NS {
template<class T>
class X {};
template class X<int>;
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03, "NS");
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
// Check that the ClassTemplateSpecializationDecl is NOT the child of the
// ClassTemplateDecl.
auto Pattern = namespaceDecl(has(classTemplateDecl(
hasName("X"), unless(has(classTemplateSpecializationDecl())))));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(From, Pattern));
EXPECT_TRUE(MatchVerifier<Decl>{}.match(To, Pattern));
// Check that the ClassTemplateSpecializationDecl is the child of the
// NamespaceDecl.
Pattern = namespaceDecl(has(classTemplateSpecializationDecl(hasName("X"))));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(From, Pattern));
EXPECT_TRUE(MatchVerifier<Decl>{}.match(To, Pattern));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
CXXRecordDeclFieldsShouldBeInCorrectOrder) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) =
getImportedDecl(
"struct declToImport { int a; int b; };",
Lang_CXX11, "", Lang_CXX11);
MatchVerifier<Decl> Verifier;
ASSERT_TRUE(Verifier.match(From, cxxRecordDecl(hasFieldOrder({"a", "b"}))));
EXPECT_TRUE(Verifier.match(To, cxxRecordDecl(hasFieldOrder({"a", "b"}))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Reorder fields after structure import is finished 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
2019-07-25 17:07:17 +08:00
CXXRecordDeclFieldOrderShouldNotDependOnImportOrder) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
// The original recursive algorithm of ASTImporter first imports 'c' then
// 'b' and lastly 'a'. Therefore we must restore the order somehow.
R"s(
struct declToImport {
int a = c + b;
int b = 1;
int c = 2;
};
)s",
Lang_CXX11, "", Lang_CXX11);
MatchVerifier<Decl> Verifier;
ASSERT_TRUE(
Verifier.match(From, cxxRecordDecl(hasFieldOrder({"a", "b", "c"}))));
EXPECT_TRUE(
Verifier.match(To, cxxRecordDecl(hasFieldOrder({"a", "b", "c"}))));
}
[ASTImporter] At import of records re-order indirect fields too. 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
2019-09-02 15:17:01 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
CXXRecordDeclFieldAndIndirectFieldOrder) {
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
// First field is "a", then the field for unnamed union, then "b" and "c"
// from it (indirect fields), then "d".
R"s(
struct declToImport {
int a = d;
union {
int b;
int c;
};
int d;
};
)s",
Lang_CXX11, "", Lang_CXX11);
MatchVerifier<Decl> Verifier;
ASSERT_TRUE(Verifier.match(
From, cxxRecordDecl(hasFieldOrder({"a", "", "b", "c", "d"}))));
EXPECT_TRUE(Verifier.match(
To, cxxRecordDecl(hasFieldOrder({"a", "", "b", "c", "d"}))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ShouldImportImplicitCXXRecordDecl) {
[ASTImporter] Fix missing implict CXXRecordDecl in ClassTemplateSpecializationDecl 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
2018-05-23 22:24:02 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
struct declToImport {
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Fix missing implict CXXRecordDecl in ClassTemplateSpecializationDecl 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
2018-05-23 22:24:02 +08:00
MatchVerifier<Decl> Verifier;
// Match the implicit Decl.
auto Matcher = cxxRecordDecl(has(cxxRecordDecl()));
ASSERT_TRUE(Verifier.match(From, Matcher));
EXPECT_TRUE(Verifier.match(To, Matcher));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ShouldImportImplicitCXXRecordDeclOfClassTemplate) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
template <typename U>
struct declToImport {
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
MatchVerifier<Decl> Verifier;
// Match the implicit Decl.
auto Matcher = classTemplateDecl(has(cxxRecordDecl(has(cxxRecordDecl()))));
ASSERT_TRUE(Verifier.match(From, Matcher));
EXPECT_TRUE(Verifier.match(To, Matcher));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ShouldImportImplicitCXXRecordDeclOfClassTemplateSpecializationDecl) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
template<class T>
class Base {};
class declToImport : public Base<declToImport> {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto hasImplicitClass = has(cxxRecordDecl());
auto Pattern = translationUnitDecl(has(classTemplateDecl(
hasName("Base"),
has(classTemplateSpecializationDecl(hasImplicitClass)))));
ASSERT_TRUE(
MatchVerifier<Decl>{}.match(From->getTranslationUnitDecl(), Pattern));
EXPECT_TRUE(
MatchVerifier<Decl>{}.match(To->getTranslationUnitDecl(), Pattern));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, IDNSOrdinary) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From, *To;
std::tie(From, To) =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getImportedDecl("void declToImport() {}", Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
MatchVerifier<Decl> Verifier;
auto Matcher = functionDecl();
ASSERT_TRUE(Verifier.match(From, Matcher));
EXPECT_TRUE(Verifier.match(To, Matcher));
EXPECT_EQ(From->getIdentifierNamespace(), To->getIdentifierNamespace());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, IDNSOfNonmemberOperator) {
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *FromTU = getTuDecl(
R"(
struct X {};
void operator<<(int, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *From = LastDeclMatcher<Decl>{}.match(FromTU, functionDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
const Decl *To = Import(From, Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
EXPECT_EQ(From->getIdentifierNamespace(), To->getIdentifierNamespace());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
ShouldImportMembersOfClassTemplateSpecializationDecl) {
Decl *From, *To;
std::tie(From, To) = getImportedDecl(
R"(
template<class T>
class Base { int a; };
class declToImport : Base<declToImport> {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto Pattern = translationUnitDecl(has(classTemplateDecl(
hasName("Base"),
has(classTemplateSpecializationDecl(has(fieldDecl(hasName("a"))))))));
ASSERT_TRUE(
MatchVerifier<Decl>{}.match(From->getTranslationUnitDecl(), Pattern));
EXPECT_TRUE(
MatchVerifier<Decl>{}.match(To->getTranslationUnitDecl(), Pattern));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportDefinitionOfClassTemplateAfterFwdDecl) {
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
{
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
auto *FromD = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
}
{
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B {
void f();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
FunctionDecl *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
auto *FromCTD = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToCTD = cast<ClassTemplateDecl>(Import(FromCTD, Lang_CXX03));
[ASTImporter] Extend lookup logic in class templates 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
2018-05-15 19:09:07 +08:00
EXPECT_TRUE(ToCTD->isThisDeclarationADefinition());
}
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
ImportDefinitionOfClassTemplateIfThereIsAnExistingFwdDeclAndDefinition) {
Decl *ToTU = getToTuDecl(
R"(
template <typename T>
struct B {
void f();
};
template <typename T>
struct B;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
ASSERT_EQ(1u, DeclCounterWithPredicate<ClassTemplateDecl>(
[](const ClassTemplateDecl *T) {
return T->isThisDeclarationADefinition();
})
.match(ToTU, classTemplateDecl()));
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B {
void f();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
ClassTemplateDecl *FromD = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
// We should have only one definition.
EXPECT_EQ(1u, DeclCounterWithPredicate<ClassTemplateDecl>(
[](const ClassTemplateDecl *T) {
return T->isThisDeclarationADefinition();
})
.match(ToTU, classTemplateDecl()));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
ImportDefinitionOfClassIfThereIsAnExistingFwdDeclAndDefinition) {
Decl *ToTU = getToTuDecl(
R"(
struct B {
void f();
};
struct B;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
ASSERT_EQ(2u, DeclCounter<CXXRecordDecl>().match(
Fix ASTImporterTest on Windows after r333082 With MS compatibility, Sema adds an implicit definition of type_info, which was causing the matchers to return 3 instead of 2. llvm-svn: 333170
2018-05-24 18:49:38 +08:00
ToTU, cxxRecordDecl(unless(isImplicit()))));
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
Decl *FromTU = getTuDecl(
R"(
struct B {
void f();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
auto *FromD = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
EXPECT_EQ(2u, DeclCounter<CXXRecordDecl>().match(
Fix ASTImporterTest on Windows after r333082 With MS compatibility, Sema adds an implicit definition of type_info, which was causing the matchers to return 3 instead of 2. llvm-svn: 333170
2018-05-24 18:49:38 +08:00
ToTU, cxxRecordDecl(unless(isImplicit()))));
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
}
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
static void CompareSourceLocs(FullSourceLoc Loc1, FullSourceLoc Loc2) {
EXPECT_EQ(Loc1.getExpansionLineNumber(), Loc2.getExpansionLineNumber());
EXPECT_EQ(Loc1.getExpansionColumnNumber(), Loc2.getExpansionColumnNumber());
EXPECT_EQ(Loc1.getSpellingLineNumber(), Loc2.getSpellingLineNumber());
EXPECT_EQ(Loc1.getSpellingColumnNumber(), Loc2.getSpellingColumnNumber());
}
static void CompareSourceRanges(SourceRange Range1, SourceRange Range2,
SourceManager &SM1, SourceManager &SM2) {
CompareSourceLocs(FullSourceLoc{ Range1.getBegin(), SM1 },
FullSourceLoc{ Range2.getBegin(), SM2 });
CompareSourceLocs(FullSourceLoc{ Range1.getEnd(), SM1 },
FullSourceLoc{ Range2.getEnd(), SM2 });
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportSourceLocs) {
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
Decl *FromTU = getTuDecl(
R"(
#define MFOO(arg) arg = arg + 1
void foo() {
int a = 5;
MFOO(a);
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
auto FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto ToD = Import(FromD, Lang_CXX03);
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
auto ToLHS = LastDeclMatcher<DeclRefExpr>().match(ToD, declRefExpr());
auto FromLHS = LastDeclMatcher<DeclRefExpr>().match(FromTU, declRefExpr());
auto ToRHS = LastDeclMatcher<IntegerLiteral>().match(ToD, integerLiteral());
auto FromRHS =
LastDeclMatcher<IntegerLiteral>().match(FromTU, integerLiteral());
SourceManager &ToSM = ToAST->getASTContext().getSourceManager();
SourceManager &FromSM = FromD->getASTContext().getSourceManager();
CompareSourceRanges(ToD->getSourceRange(), FromD->getSourceRange(), ToSM,
FromSM);
CompareSourceRanges(ToLHS->getSourceRange(), FromLHS->getSourceRange(), ToSM,
FromSM);
CompareSourceRanges(ToRHS->getSourceRange(), FromRHS->getSourceRange(), ToSM,
FromSM);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportNestedMacro) {
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
Decl *FromTU = getTuDecl(
R"(
#define FUNC_INT void declToImport
#define FUNC FUNC_INT
FUNC(int a);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
auto FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto ToD = Import(FromD, Lang_CXX03);
[ASTImporter] import macro source locations Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
2018-07-04 21:34:05 +08:00
SourceManager &ToSM = ToAST->getASTContext().getSourceManager();
SourceManager &FromSM = FromD->getASTContext().getSourceManager();
CompareSourceRanges(ToD->getSourceRange(), FromD->getSourceRange(), ToSM,
FromSM);
}
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
TEST_P(
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
ASTImporterOptionSpecificTestBase,
ImportDefinitionOfClassTemplateSpecIfThereIsAnExistingFwdDeclAndDefinition) {
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
Decl *ToTU = getToTuDecl(
R"(
template <typename T>
struct B;
template <>
struct B<int> {};
template <>
struct B<int>;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
// We should have only one definition.
ASSERT_EQ(1u, DeclCounterWithPredicate<ClassTemplateSpecializationDecl>(
[](const ClassTemplateSpecializationDecl *T) {
return T->isThisDeclarationADefinition();
})
.match(ToTU, classTemplateSpecializationDecl()));
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B;
template <>
struct B<int> {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
auto *FromD = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
Fix duplicate class template definitions problem 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
2018-05-23 21:53:36 +08:00
// We should have only one definition.
EXPECT_EQ(1u, DeclCounterWithPredicate<ClassTemplateSpecializationDecl>(
[](const ClassTemplateSpecializationDecl *T) {
return T->isThisDeclarationADefinition();
})
.match(ToTU, classTemplateSpecializationDecl()));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ObjectsWithUnnamedStructType) {
[ASTImporter] Fix import of objects with anonymous types 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
2018-07-05 17:51:13 +08:00
Decl *FromTU = getTuDecl(
R"(
struct { int a; int b; } object0 = { 2, 3 };
struct { int x; int y; int z; } object1;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix import of objects with anonymous types 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
2018-07-05 17:51:13 +08:00
auto *Obj0 =
FirstDeclMatcher<VarDecl>().match(FromTU, varDecl(hasName("object0")));
auto *From0 = getRecordDecl(Obj0);
auto *Obj1 =
FirstDeclMatcher<VarDecl>().match(FromTU, varDecl(hasName("object1")));
auto *From1 = getRecordDecl(Obj1);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *To0 = Import(From0, Lang_CXX03);
auto *To1 = Import(From1, Lang_CXX03);
[ASTImporter] Fix import of objects with anonymous types 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
2018-07-05 17:51:13 +08:00
EXPECT_TRUE(To0);
EXPECT_TRUE(To1);
EXPECT_NE(To0, To1);
EXPECT_NE(To0->getCanonicalDecl(), To1->getCanonicalDecl());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, AnonymousRecords) {
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Code =
R"(
struct X {
struct { int a; };
struct { int b; };
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU0 = getTuDecl(Code, Lang_C99, "input0.c");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(Code, Lang_C99, "input1.c");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *X0 =
FirstDeclMatcher<RecordDecl>().match(FromTU0, recordDecl(hasName("X")));
auto *X1 =
FirstDeclMatcher<RecordDecl>().match(FromTU1, recordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(X0, Lang_C99);
Import(X1, Lang_C99);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// We expect no (ODR) warning during the import.
EXPECT_EQ(0u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
EXPECT_EQ(1u,
DeclCounter<RecordDecl>().match(ToTU, recordDecl(hasName("X"))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, AnonymousRecordsReversed) {
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Decl *FromTU0 = getTuDecl(
R"(
struct X {
struct { int a; };
struct { int b; };
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "input0.c");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Decl *FromTU1 = getTuDecl(
R"(
struct X { // reversed order
struct { int b; };
struct { int a; };
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "input1.c");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *X0 =
FirstDeclMatcher<RecordDecl>().match(FromTU0, recordDecl(hasName("X")));
auto *X1 =
FirstDeclMatcher<RecordDecl>().match(FromTU1, recordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(X0, Lang_C99);
Import(X1, Lang_C99);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// We expect one (ODR) warning during the import.
EXPECT_EQ(1u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
EXPECT_EQ(1u,
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
DeclCounter<RecordDecl>().match(ToTU, recordDecl(hasName("X"))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportDoesUpdateUsedFlag) {
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
auto Pattern = varDecl(hasName("x"));
VarDecl *Imported1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("extern int x;", Lang_CXX03, "input0.cc");
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Imported1 = cast<VarDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
}
VarDecl *Imported2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("int x;", Lang_CXX03, "input1.cc");
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Imported2 = cast<VarDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
}
EXPECT_EQ(Imported1->getCanonicalDecl(), Imported2->getCanonicalDecl());
EXPECT_FALSE(Imported2->isUsed(false));
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("extern int x; int f() { return x; }", Lang_CXX03,
"input2.cc");
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
}
EXPECT_TRUE(Imported2->isUsed(false));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportDoesUpdateUsedFlag2) {
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto Pattern = varDecl(hasName("x"));
VarDecl *ExistingD;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTU = getToTuDecl("int x = 1;", Lang_CXX03);
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
ExistingD = FirstDeclMatcher<VarDecl>().match(ToTU, Pattern);
}
EXPECT_FALSE(ExistingD->isUsed(false));
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("int x = 1; int f() { return x; }", Lang_CXX03, "input1.cc");
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
}
EXPECT_TRUE(ExistingD->isUsed(false));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportDoesUpdateUsedFlag3) {
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto Pattern = varDecl(hasName("a"));
VarDecl *ExistingD;
{
Decl *ToTU = getToTuDecl(
R"(
struct A {
static const int a = 1;
};
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
)",
Lang_CXX03);
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
ExistingD = FirstDeclMatcher<VarDecl>().match(ToTU, Pattern);
}
EXPECT_FALSE(ExistingD->isUsed(false));
{
Decl *FromTU = getTuDecl(
R"(
struct A {
static const int a = 1;
};
const int *f() { return &A::a; } // requires storage,
// thus used flag will be set
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
)",
Lang_CXX03, "input1.cc");
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto *FromFunD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
ASSERT_TRUE(FromD->isUsed(false));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromFunD, Lang_CXX03);
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
}
EXPECT_TRUE(ExistingD->isUsed(false));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ReimportWithUsedFlag) {
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
auto Pattern = varDecl(hasName("x"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("int x;", Lang_CXX03, "input0.cc");
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *Imported1 = cast<VarDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
ASSERT_FALSE(Imported1->isUsed(false));
FromD->setIsUsed();
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *Imported2 = cast<VarDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Refactor Decl creation 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
2018-07-12 17:42:05 +08:00
EXPECT_EQ(Imported1, Imported2);
EXPECT_TRUE(Imported2->isUsed(false));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ImportFunctions : ASTImporterOptionSpecificTestBase {};
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
TEST_P(ImportFunctions, ImportPrototypeOfRecursiveFunction) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f(); void f() { f(); }", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto Pattern = functionDecl(hasName("f"));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *From =
FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern); // Proto
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ImportedD = Import(From, Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *ToTU = ImportedD->getTranslationUnitDecl();
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
auto *To0 = FirstDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
auto *To1 = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ImportedD == To0);
EXPECT_FALSE(To0->doesThisDeclarationHaveABody());
EXPECT_TRUE(To1->doesThisDeclarationHaveABody());
EXPECT_EQ(To1->getPreviousDecl(), To0);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
}
TEST_P(ImportFunctions, ImportDefinitionOfRecursiveFunction) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f(); void f() { f(); }", Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
auto Pattern = functionDecl(hasName("f"));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *From =
LastDeclMatcher<FunctionDecl>().match(FromTU, Pattern); // Def
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ImportedD = Import(From, Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
Decl *ToTU = ImportedD->getTranslationUnitDecl();
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
auto *To0 = FirstDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
auto *To1 = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ImportedD == To1);
EXPECT_FALSE(To0->doesThisDeclarationHaveABody());
EXPECT_TRUE(To1->doesThisDeclarationHaveABody());
EXPECT_EQ(To1->getPreviousDecl(), To0);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
}
TEST_P(ImportFunctions, OverriddenMethodsShouldBeImported) {
auto Code =
R"(
struct B { virtual void f(); };
void B::f() {}
struct D : B { void f(); };
)";
auto Pattern =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
CXXMethodDecl *Proto =
FirstDeclMatcher<CXXMethodDecl>().match(FromTU, Pattern);
ASSERT_EQ(Proto->size_overridden_methods(), 1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXMethodDecl *To = cast<CXXMethodDecl>(Import(Proto, Lang_CXX03));
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
EXPECT_EQ(To->size_overridden_methods(), 1u);
}
TEST_P(ImportFunctions, VirtualFlagShouldBePreservedWhenImportingPrototype) {
auto Code =
R"(
struct B { virtual void f(); };
void B::f() {}
)";
auto Pattern =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B"))));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
CXXMethodDecl *Proto =
FirstDeclMatcher<CXXMethodDecl>().match(FromTU, Pattern);
CXXMethodDecl *Def = LastDeclMatcher<CXXMethodDecl>().match(FromTU, Pattern);
ASSERT_TRUE(Proto->isVirtual());
ASSERT_TRUE(Def->isVirtual());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXMethodDecl *To = cast<CXXMethodDecl>(Import(Proto, Lang_CXX03));
[ASTImporter] Add test helper Fixture 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
2018-03-31 06:03:29 +08:00
EXPECT_TRUE(To->isVirtual());
}
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
TEST_P(ImportFunctions,
ImportDefinitionIfThereIsAnExistingDefinitionAndFwdDecl) {
Decl *ToTU = getToTuDecl(
R"(
void f() {}
void f();
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
ASSERT_EQ(1u,
DeclCounterWithPredicate<FunctionDecl>([](const FunctionDecl *FD) {
return FD->doesThisDeclarationHaveABody();
}).match(ToTU, functionDecl()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f() {}", Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
EXPECT_EQ(1u,
DeclCounterWithPredicate<FunctionDecl>([](const FunctionDecl *FD) {
return FD->doesThisDeclarationHaveABody();
}).match(ToTU, functionDecl()));
}
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
TEST_P(ImportFunctions, ImportOverriddenMethodTwice) {
auto Code =
R"(
struct B { virtual void f(); };
struct D:B { void f(); };
)";
auto BFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B"))));
auto DFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU0 = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *DF = FirstDeclMatcher<CXXMethodDecl>().match(FromTU0, DFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(DF, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(Code, Lang_CXX03, "input1.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *BF = FirstDeclMatcher<CXXMethodDecl>().match(FromTU1, BFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(BF, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, DFP), 1u);
}
TEST_P(ImportFunctions, ImportOverriddenMethodTwiceDefinitionFirst) {
auto CodeWithoutDef =
R"(
struct B { virtual void f(); };
struct D:B { void f(); };
)";
auto CodeWithDef =
R"(
struct B { virtual void f(){}; };
struct D:B { void f(){}; };
)";
auto BFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B"))));
auto DFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))));
auto BFDefP = cxxMethodDecl(
hasName("f"), hasParent(cxxRecordDecl(hasName("B"))), isDefinition());
auto DFDefP = cxxMethodDecl(
hasName("f"), hasParent(cxxRecordDecl(hasName("D"))), isDefinition());
auto FDefAllP = cxxMethodDecl(hasName("f"), isDefinition());
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(CodeWithDef, Lang_CXX03, "input0.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *FromD = FirstDeclMatcher<CXXMethodDecl>().match(FromTU, DFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
}
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(CodeWithoutDef, Lang_CXX03, "input1.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *FromB = FirstDeclMatcher<CXXMethodDecl>().match(FromTU, BFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromB, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
}
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, DFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFDefP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, DFDefP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, FDefAllP), 2u);
}
TEST_P(ImportFunctions, ImportOverriddenMethodTwiceOutOfClassDef) {
auto Code =
R"(
struct B { virtual void f(); };
struct D:B { void f(); };
void B::f(){};
)";
auto BFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B"))));
auto BFDefP = cxxMethodDecl(
hasName("f"), hasParent(cxxRecordDecl(hasName("B"))), isDefinition());
auto DFP = cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))),
unless(isDefinition()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU0 = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *D = FirstDeclMatcher<CXXMethodDecl>().match(FromTU0, DFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(D, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(Code, Lang_CXX03, "input1.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *B = FirstDeclMatcher<CXXMethodDecl>().match(FromTU1, BFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(B, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFDefP), 0u);
auto *ToB = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("B")));
auto *ToBFInClass = FirstDeclMatcher<CXXMethodDecl>().match(ToTU, BFP);
auto *ToBFOutOfClass = FirstDeclMatcher<CXXMethodDecl>().match(
ToTU, cxxMethodDecl(hasName("f"), isDefinition()));
// The definition should be out-of-class.
EXPECT_NE(ToBFInClass, ToBFOutOfClass);
EXPECT_NE(ToBFInClass->getLexicalDeclContext(),
ToBFOutOfClass->getLexicalDeclContext());
EXPECT_EQ(ToBFOutOfClass->getDeclContext(), ToB);
EXPECT_EQ(ToBFOutOfClass->getLexicalDeclContext(), ToTU);
// Check that the redecl chain is intact.
EXPECT_EQ(ToBFOutOfClass->getPreviousDecl(), ToBFInClass);
}
TEST_P(ImportFunctions,
ImportOverriddenMethodTwiceOutOfClassDefInSeparateCode) {
auto CodeTU0 =
R"(
struct B { virtual void f(); };
struct D:B { void f(); };
)";
auto CodeTU1 =
R"(
struct B { virtual void f(); };
struct D:B { void f(); };
void B::f(){}
void D::f(){}
void foo(B &b, D &d) { b.f(); d.f(); }
)";
auto BFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("B"))));
auto BFDefP = cxxMethodDecl(
hasName("f"), hasParent(cxxRecordDecl(hasName("B"))), isDefinition());
auto DFP =
cxxMethodDecl(hasName("f"), hasParent(cxxRecordDecl(hasName("D"))));
auto DFDefP = cxxMethodDecl(
hasName("f"), hasParent(cxxRecordDecl(hasName("D"))), isDefinition());
auto FooDef = functionDecl(hasName("foo"));
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU0 = getTuDecl(CodeTU0, Lang_CXX03, "input0.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *D = FirstDeclMatcher<CXXMethodDecl>().match(FromTU0, DFP);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(D, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
}
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(CodeTU1, Lang_CXX03, "input1.cc");
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
auto *Foo = FirstDeclMatcher<FunctionDecl>().match(FromTU1, FooDef);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(Foo, Lang_CXX03);
[ASTImporter] Fix handling of overriden methods during ASTImport 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
2019-01-29 05:55:33 +08:00
}
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, DFP), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, BFDefP), 0u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, DFDefP), 0u);
auto *ToB = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("B")));
auto *ToD = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("D")));
auto *ToBFInClass = FirstDeclMatcher<CXXMethodDecl>().match(ToTU, BFP);
auto *ToBFOutOfClass = FirstDeclMatcher<CXXMethodDecl>().match(
ToTU, cxxMethodDecl(hasName("f"), isDefinition()));
auto *ToDFInClass = FirstDeclMatcher<CXXMethodDecl>().match(ToTU, DFP);
auto *ToDFOutOfClass = LastDeclMatcher<CXXMethodDecl>().match(
ToTU, cxxMethodDecl(hasName("f"), isDefinition()));
// The definition should be out-of-class.
EXPECT_NE(ToBFInClass, ToBFOutOfClass);
EXPECT_NE(ToBFInClass->getLexicalDeclContext(),
ToBFOutOfClass->getLexicalDeclContext());
EXPECT_EQ(ToBFOutOfClass->getDeclContext(), ToB);
EXPECT_EQ(ToBFOutOfClass->getLexicalDeclContext(), ToTU);
EXPECT_NE(ToDFInClass, ToDFOutOfClass);
EXPECT_NE(ToDFInClass->getLexicalDeclContext(),
ToDFOutOfClass->getLexicalDeclContext());
EXPECT_EQ(ToDFOutOfClass->getDeclContext(), ToD);
EXPECT_EQ(ToDFOutOfClass->getLexicalDeclContext(), ToTU);
// Check that the redecl chain is intact.
EXPECT_EQ(ToBFOutOfClass->getPreviousDecl(), ToBFInClass);
EXPECT_EQ(ToDFOutOfClass->getPreviousDecl(), ToDFInClass);
}
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportVariableChainInC) {
std::string Code = "static int v; static int v = 0;";
auto Pattern = varDecl(hasName("v"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTu = getTuDecl(Code, Lang_C99, "input0.c");
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
auto *From0 = FirstDeclMatcher<VarDecl>().match(FromTu, Pattern);
auto *From1 = LastDeclMatcher<VarDecl>().match(FromTu, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *To0 = Import(From0, Lang_C99);
auto *To1 = Import(From1, Lang_C99);
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
EXPECT_TRUE(To0);
ASSERT_TRUE(To1);
EXPECT_NE(To0, To1);
EXPECT_EQ(To1->getPreviousDecl(), To0);
}
TEST_P(ImportFunctions, ImportFromDifferentScopedAnonNamespace) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTu =
getTuDecl("namespace NS0 { namespace { void f(); } }"
"namespace NS1 { namespace { void f(); } }",
Lang_CXX03, "input0.cc");
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
auto Pattern = functionDecl(hasName("f"));
auto *FromF0 = FirstDeclMatcher<FunctionDecl>().match(FromTu, Pattern);
auto *FromF1 = LastDeclMatcher<FunctionDecl>().match(FromTu, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToF0 = Import(FromF0, Lang_CXX03);
auto *ToF1 = Import(FromF1, Lang_CXX03);
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
EXPECT_TRUE(ToF0);
ASSERT_TRUE(ToF1);
EXPECT_NE(ToF0, ToF1);
EXPECT_FALSE(ToF1->getPreviousDecl());
}
TEST_P(ImportFunctions, ImportFunctionFromUnnamedNamespace) {
{
Decl *FromTU = getTuDecl("namespace { void f() {} } void g0() { f(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("g0")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
}
{
Decl *FromTU =
getTuDecl("namespace { void f() { int a; } } void g1() { f(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("g1")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter] Check visibility/linkage of functions and variables 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
2019-02-14 21:07:03 +08:00
}
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, functionDecl(hasName("f"))),
2u);
}
[ASTImporter] Import every Decl in lambda record 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
2019-02-15 20:04:05 +08:00
TEST_P(ImportFunctions, ImportImplicitFunctionsInLambda) {
Decl *FromTU = getTuDecl(
R"(
void foo() {
(void)[]() { ; };
}
)",
Lang_CXX11);
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Import every Decl in lambda record 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
2019-02-15 20:04:05 +08:00
EXPECT_TRUE(ToD);
CXXRecordDecl *LambdaRec =
cast<LambdaExpr>(cast<CStyleCastExpr>(
*cast<CompoundStmt>(ToD->getBody())->body_begin())
->getSubExpr())
->getLambdaClass();
EXPECT_TRUE(LambdaRec->getDestructor());
}
[ASTImporter] Import member expr with explicit template args 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
2019-03-07 21:38:20 +08:00
TEST_P(ImportFunctions,
CallExprOfMemberFunctionTemplateWithExplicitTemplateArgs) {
Decl *FromTU = getTuDecl(
R"(
struct X {
template <typename T>
void foo(){}
};
void f() {
X x;
x.foo<int>();
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Import member expr with explicit template args 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
2019-03-07 21:38:20 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Import member expr with explicit template args 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
2019-03-07 21:38:20 +08:00
EXPECT_TRUE(ToD);
EXPECT_TRUE(MatchVerifier<FunctionDecl>().match(
ToD, functionDecl(hasName("f"), hasDescendant(declRefExpr()))));
}
TEST_P(ImportFunctions,
DependentCallExprOfMemberFunctionTemplateWithExplicitTemplateArgs) {
Decl *FromTU = getTuDecl(
R"(
struct X {
template <typename T>
void foo(){}
};
template <typename T>
void f() {
X x;
x.foo<T>();
}
void g() {
f<int>();
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Import member expr with explicit template args 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
2019-03-07 21:38:20 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("g")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Import member expr with explicit template args 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
2019-03-07 21:38:20 +08:00
EXPECT_TRUE(ToD);
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_TRUE(MatchVerifier<TranslationUnitDecl>().match(
ToTU, translationUnitDecl(hasDescendant(
functionDecl(hasName("f"), hasDescendant(declRefExpr()))))));
}
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
struct ImportFunctionTemplates : ASTImporterOptionSpecificTestBase {};
TEST_P(ImportFunctionTemplates, ImportFunctionTemplateInRecordDeclTwice) {
auto Code =
R"(
class X {
template <class T>
void f(T t);
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(Code, Lang_CXX03, "input1.cc");
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
auto *FromD1 = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU1, functionTemplateDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD1 = Import(FromD1, Lang_CXX03);
Decl *FromTU2 = getTuDecl(Code, Lang_CXX03, "input2.cc");
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
auto *FromD2 = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU2, functionTemplateDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD2 = Import(FromD2, Lang_CXX03);
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
EXPECT_EQ(ToD1, ToD2);
}
TEST_P(ImportFunctionTemplates,
ImportFunctionTemplateWithDefInRecordDeclTwice) {
auto Code =
R"(
class X {
template <class T>
void f(T t);
};
template <class T>
void X::f(T t) {};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU1 = getTuDecl(Code, Lang_CXX03, "input1.cc");
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
auto *FromD1 = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU1, functionTemplateDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD1 = Import(FromD1, Lang_CXX03);
Decl *FromTU2 = getTuDecl(Code, Lang_CXX03, "input2.cc");
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
auto *FromD2 = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU2, functionTemplateDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD2 = Import(FromD2, Lang_CXX03);
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
EXPECT_EQ(ToD1, ToD2);
}
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
TEST_P(ImportFunctionTemplates,
ImportFunctionWhenThereIsAFunTemplateWithSameName) {
getToTuDecl(
R"(
template <typename T>
void foo(T) {}
void foo();
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
Decl *FromTU = getTuDecl("void foo();", Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = Import(FromD, Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
EXPECT_TRUE(ImportedD);
}
TEST_P(ImportFunctionTemplates,
ImportConstructorWhenThereIsAFunTemplateWithSameName) {
auto Code =
R"(
struct Foo {
template <typename T>
Foo(T) {}
Foo();
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getToTuDecl(Code, Lang_CXX03);
Decl *FromTU = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
auto *FromD =
LastDeclMatcher<CXXConstructorDecl>().match(FromTU, cxxConstructorDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = Import(FromD, Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
EXPECT_TRUE(ImportedD);
}
TEST_P(ImportFunctionTemplates,
ImportOperatorWhenThereIsAFunTemplateWithSameName) {
getToTuDecl(
R"(
template <typename T>
void operator<(T,T) {}
struct X{};
void operator<(X, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
Decl *FromTU = getTuDecl(
R"(
struct X{};
void operator<(X, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
auto *FromD = LastDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasOverloadedOperatorName("<")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = Import(FromD, Lang_CXX03);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
EXPECT_TRUE(ImportedD);
}
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
struct ImportFriendFunctions : ImportFunctions {};
TEST_P(ImportFriendFunctions, ImportFriendFunctionRedeclChainProto) {
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl("struct X { friend void f(); };"
"void f();",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_FALSE(ImportedD->doesThisDeclarationHaveABody());
auto *ToFD = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_FALSE(ToFD->doesThisDeclarationHaveABody());
EXPECT_EQ(ToFD->getPreviousDecl(), ImportedD);
}
TEST_P(ImportFriendFunctions,
ImportFriendFunctionRedeclChainProto_OutOfClassProtoFirst) {
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl("void f();"
"struct X { friend void f(); };",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_FALSE(ImportedD->doesThisDeclarationHaveABody());
auto *ToFD = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_FALSE(ToFD->doesThisDeclarationHaveABody());
EXPECT_EQ(ToFD->getPreviousDecl(), ImportedD);
}
TEST_P(ImportFriendFunctions, ImportFriendFunctionRedeclChainDef) {
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl("struct X { friend void f(){} };"
"void f();",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_TRUE(ImportedD->doesThisDeclarationHaveABody());
auto *ToFD = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_FALSE(ToFD->doesThisDeclarationHaveABody());
EXPECT_EQ(ToFD->getPreviousDecl(), ImportedD);
}
TEST_P(ImportFriendFunctions,
ImportFriendFunctionRedeclChainDef_OutOfClassDef) {
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl("struct X { friend void f(); };"
"void f(){}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_FALSE(ImportedD->doesThisDeclarationHaveABody());
auto *ToFD = LastDeclMatcher<FunctionDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ToFD->doesThisDeclarationHaveABody());
EXPECT_EQ(ToFD->getPreviousDecl(), ImportedD);
}
[ASTImporter] Enable disabled but passing tests Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62066 llvm-svn: 361139
2019-05-20 18:38:14 +08:00
TEST_P(ImportFriendFunctions, ImportFriendFunctionRedeclChainDefWithClass) {
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl(
R"(
class X;
void f(X *x){}
class X{
friend void f(X *x);
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_TRUE(ImportedD->doesThisDeclarationHaveABody());
auto *InClassFD = cast<FunctionDecl>(FirstDeclMatcher<FriendDecl>()
.match(ToTU, friendDecl())
->getFriendDecl());
EXPECT_FALSE(InClassFD->doesThisDeclarationHaveABody());
EXPECT_EQ(InClassFD->getPreviousDecl(), ImportedD);
// The parameters must refer the same type
EXPECT_EQ((*InClassFD->param_begin())->getOriginalType(),
(*ImportedD->param_begin())->getOriginalType());
}
TEST_P(ImportFriendFunctions,
[ASTImporter] Enable disabled but passing tests Reviewers: a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D62066 llvm-svn: 361139
2019-05-20 18:38:14 +08:00
ImportFriendFunctionRedeclChainDefWithClass_ImportTheProto) {
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Pattern = functionDecl(hasName("f"));
Decl *FromTU = getTuDecl(
R"(
class X;
void f(X *x){}
class X{
friend void f(X *x);
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = LastDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_FALSE(ImportedD->doesThisDeclarationHaveABody());
auto *OutOfClassFD = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(unless(hasParent(friendDecl()))));
EXPECT_TRUE(OutOfClassFD->doesThisDeclarationHaveABody());
EXPECT_EQ(ImportedD->getPreviousDecl(), OutOfClassFD);
// The parameters must refer the same type
EXPECT_EQ((*OutOfClassFD->param_begin())->getOriginalType(),
(*ImportedD->param_begin())->getOriginalType());
}
TEST_P(ImportFriendFunctions, ImportFriendFunctionFromMultipleTU) {
auto Pattern = functionDecl(hasName("f"));
FunctionDecl *ImportedD;
{
Decl *FromTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getTuDecl("struct X { friend void f(){} };", Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ImportedD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
}
FunctionDecl *ImportedD1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("void f();", Lang_CXX03, "input1.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ImportedD1 = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
}
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_TRUE(ImportedD->doesThisDeclarationHaveABody());
EXPECT_FALSE(ImportedD1->doesThisDeclarationHaveABody());
EXPECT_EQ(ImportedD1->getPreviousDecl(), ImportedD);
}
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
TEST_P(ImportFriendFunctions, Lookup) {
auto FunctionPattern = functionDecl(hasName("f"));
auto ClassPattern = cxxRecordDecl(hasName("X"));
TranslationUnitDecl *FromTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getTuDecl("struct X { friend void f(); };", Lang_CXX03, "input0.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU, FunctionPattern);
ASSERT_TRUE(FromD->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_FALSE(FromD->isInIdentifierNamespace(Decl::IDNS_Ordinary));
{
auto FromName = FromD->getDeclName();
auto *Class = FirstDeclMatcher<CXXRecordDecl>().match(FromTU, ClassPattern);
auto LookupRes = Class->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 0u);
LookupRes = FromTU->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 1u);
}
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = cast<FunctionDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto ToName = ToD->getDeclName();
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto *Class = FirstDeclMatcher<CXXRecordDecl>().match(ToTU, ClassPattern);
auto LookupRes = Class->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 0u);
LookupRes = ToTU->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, FunctionPattern), 1u);
auto *To0 = FirstDeclMatcher<FunctionDecl>().match(ToTU, FunctionPattern);
EXPECT_TRUE(To0->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_FALSE(To0->isInIdentifierNamespace(Decl::IDNS_Ordinary));
}
recommit: [ASTImporter] Friend class decl should not be visible in its context Summary: In the past we had to use DeclContext::makeDeclVisibleInContext to make friend declarations available for subsequent lookup calls and this way we could chain (redecl) the structurally equivalent decls. By doing this we created an AST that improperly made declarations visible in some contexts, so the AST was malformed. Since we use the importer specific lookup this is no longer necessary, because with that we can find every previous nodes. Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71020
2019-12-05 00:12:08 +08:00
TEST_P(ImportFriendFunctions, LookupWithProtoAfter) {
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto FunctionPattern = functionDecl(hasName("f"));
auto ClassPattern = cxxRecordDecl(hasName("X"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU =
getTuDecl("struct X { friend void f(); };"
// This proto decl makes f available to normal
// lookup, otherwise it is hidden.
// Normal C++ lookup (implemented in
// `clang::Sema::CppLookupName()` and in `LookupDirect()`)
// returns the found `NamedDecl` only if the set IDNS is matched
"void f();",
Lang_CXX03, "input0.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromFriend =
FirstDeclMatcher<FunctionDecl>().match(FromTU, FunctionPattern);
auto *FromNormal =
LastDeclMatcher<FunctionDecl>().match(FromTU, FunctionPattern);
ASSERT_TRUE(FromFriend->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_FALSE(FromFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
ASSERT_FALSE(FromNormal->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_TRUE(FromNormal->isInIdentifierNamespace(Decl::IDNS_Ordinary));
auto FromName = FromFriend->getDeclName();
auto *FromClass =
FirstDeclMatcher<CXXRecordDecl>().match(FromTU, ClassPattern);
auto LookupRes = FromClass->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 0u);
LookupRes = FromTU->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToFriend = cast<FunctionDecl>(Import(FromFriend, Lang_CXX03));
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto ToName = ToFriend->getDeclName();
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto *ToClass = FirstDeclMatcher<CXXRecordDecl>().match(ToTU, ClassPattern);
LookupRes = ToClass->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 0u);
LookupRes = ToTU->noload_lookup(ToName);
// Test is disabled because this result is 2.
EXPECT_EQ(LookupRes.size(), 1u);
ASSERT_EQ(DeclCounter<FunctionDecl>().match(ToTU, FunctionPattern), 2u);
ToFriend = FirstDeclMatcher<FunctionDecl>().match(ToTU, FunctionPattern);
auto *ToNormal = LastDeclMatcher<FunctionDecl>().match(ToTU, FunctionPattern);
EXPECT_TRUE(ToFriend->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_FALSE(ToFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
EXPECT_FALSE(ToNormal->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_TRUE(ToNormal->isInIdentifierNamespace(Decl::IDNS_Ordinary));
}
TEST_P(ImportFriendFunctions, LookupWithProtoBefore) {
auto FunctionPattern = functionDecl(hasName("f"));
auto ClassPattern = cxxRecordDecl(hasName("X"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl("void f();"
"struct X { friend void f(); };",
Lang_CXX03, "input0.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromNormal =
FirstDeclMatcher<FunctionDecl>().match(FromTU, FunctionPattern);
auto *FromFriend =
LastDeclMatcher<FunctionDecl>().match(FromTU, FunctionPattern);
ASSERT_FALSE(FromNormal->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_TRUE(FromNormal->isInIdentifierNamespace(Decl::IDNS_Ordinary));
ASSERT_TRUE(FromFriend->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_TRUE(FromFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
auto FromName = FromNormal->getDeclName();
auto *FromClass =
FirstDeclMatcher<CXXRecordDecl>().match(FromTU, ClassPattern);
auto LookupRes = FromClass->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 0u);
LookupRes = FromTU->noload_lookup(FromName);
ASSERT_EQ(LookupRes.size(), 1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToNormal = cast<FunctionDecl>(Import(FromNormal, Lang_CXX03));
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto ToName = ToNormal->getDeclName();
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto *ToClass = FirstDeclMatcher<CXXRecordDecl>().match(ToTU, ClassPattern);
LookupRes = ToClass->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 0u);
LookupRes = ToTU->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, FunctionPattern), 2u);
ToNormal = FirstDeclMatcher<FunctionDecl>().match(ToTU, FunctionPattern);
auto *ToFriend = LastDeclMatcher<FunctionDecl>().match(ToTU, FunctionPattern);
EXPECT_FALSE(ToNormal->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_TRUE(ToNormal->isInIdentifierNamespace(Decl::IDNS_Ordinary));
EXPECT_TRUE(ToFriend->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_TRUE(ToFriend->isInIdentifierNamespace(Decl::IDNS_Ordinary));
}
TEST_P(ImportFriendFunctions, ImportFriendChangesLookup) {
auto Pattern = functionDecl(hasName("f"));
TranslationUnitDecl *FromNormalTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getTuDecl("void f();", Lang_CXX03, "input0.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromNormalF =
FirstDeclMatcher<FunctionDecl>().match(FromNormalTU, Pattern);
TranslationUnitDecl *FromFriendTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getTuDecl("class X { friend void f(); };", Lang_CXX03, "input1.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromFriendF =
FirstDeclMatcher<FunctionDecl>().match(FromFriendTU, Pattern);
auto FromNormalName = FromNormalF->getDeclName();
auto FromFriendName = FromFriendF->getDeclName();
ASSERT_TRUE(FromNormalF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
ASSERT_FALSE(FromNormalF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
ASSERT_FALSE(FromFriendF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
ASSERT_TRUE(FromFriendF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
auto LookupRes = FromNormalTU->noload_lookup(FromNormalName);
ASSERT_EQ(LookupRes.size(), 1u);
LookupRes = FromFriendTU->noload_lookup(FromFriendName);
ASSERT_EQ(LookupRes.size(), 1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToNormalF = cast<FunctionDecl>(Import(FromNormalF, Lang_CXX03));
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto ToName = ToNormalF->getDeclName();
EXPECT_TRUE(ToNormalF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
EXPECT_FALSE(ToNormalF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
LookupRes = ToTU->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 1u);
Lift VFS from clang to llvm (NFC) 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
2018-10-10 21:27:25 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToFriendF = cast<FunctionDecl>(Import(FromFriendF, Lang_CXX03));
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
LookupRes = ToTU->noload_lookup(ToName);
EXPECT_EQ(LookupRes.size(), 1u);
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, Pattern), 2u);
EXPECT_TRUE(ToNormalF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
EXPECT_FALSE(ToNormalF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
EXPECT_TRUE(ToFriendF->isInIdentifierNamespace(Decl::IDNS_Ordinary));
EXPECT_TRUE(ToFriendF->isInIdentifierNamespace(Decl::IDNS_OrdinaryFriend));
}
TEST_P(ImportFriendFunctions, ImportFriendList) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl("struct X { friend void f(); };"
"void f();",
Lang_CXX03, "input0.cc");
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
auto *FromFriendF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
auto *FromClass = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
auto *FromFriend = FirstDeclMatcher<FriendDecl>().match(FromTU, friendDecl());
auto FromFriends = FromClass->friends();
unsigned int FrN = 0;
for (auto Fr : FromFriends) {
ASSERT_EQ(Fr, FromFriend);
++FrN;
}
ASSERT_EQ(FrN, 1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromFriendF, Lang_CXX03);
[ASTImporter] Adding some friend function related unittests. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49798 llvm-svn: 340277
2018-08-21 22:32:21 +08:00
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto *ToClass = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("X")));
auto *ToFriend = FirstDeclMatcher<FriendDecl>().match(ToTU, friendDecl());
auto ToFriends = ToClass->friends();
FrN = 0;
for (auto Fr : ToFriends) {
EXPECT_EQ(Fr, ToFriend);
++FrN;
}
EXPECT_EQ(FrN, 1u);
}
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
AST_MATCHER_P(TagDecl, hasTypedefForAnonDecl, Matcher<TypedefNameDecl>,
InnerMatcher) {
if (auto *Typedef = Node.getTypedefNameForAnonDecl())
return InnerMatcher.matches(*Typedef, Finder, Builder);
return false;
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportDecl, ImportEnumSequential) {
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
CodeFiles Samples{{"main.c",
{"void foo();"
"void moo();"
"int main() { foo(); moo(); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99}},
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
{"foo.c",
{"typedef enum { THING_VALUE } thing_t;"
"void conflict(thing_t type);"
"void foo() { (void)THING_VALUE; }"
"void conflict(thing_t type) {}",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99}},
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
{"moo.c",
{"typedef enum { THING_VALUE } thing_t;"
"void conflict(thing_t type);"
"void moo() { conflict(THING_VALUE); }",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99}}};
[ASTImporter] Allow testing of import sequences; fix import of typedefs for anonymous decls 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
2018-04-24 18:11:53 +08:00
auto VerificationMatcher =
enumDecl(has(enumConstantDecl(hasName("THING_VALUE"))),
hasTypedefForAnonDecl(hasName("thing_t")));
ImportAction ImportFoo{"foo.c", "main.c", functionDecl(hasName("foo"))},
ImportMoo{"moo.c", "main.c", functionDecl(hasName("moo"))};
testImportSequence(
Samples, {ImportFoo, ImportMoo}, // "foo", them "moo".
// Just check that there is only one enum decl in the result AST.
"main.c", enumDecl(), VerificationMatcher);
// For different import order, result should be the same.
testImportSequence(
Samples, {ImportMoo, ImportFoo}, // "moo", them "foo".
// Check that there is only one enum decl in the result AST.
"main.c", enumDecl(), VerificationMatcher);
}
[ASTImporter] Reorder fields after structure import is finished 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
2019-07-25 17:07:17 +08:00
TEST_P(ImportDecl, ImportFieldOrder) {
MatchVerifier<Decl> Verifier;
testImport("struct declToImport {"
" int b = a + 2;"
" int a = 5;"
"};",
Lang_CXX11, "", Lang_CXX11, Verifier,
recordDecl(hasFieldOrder({"b", "a"})));
}
[ASTImporter] Support importing UnresolvedMemberExpr, DependentNameType, DependentScopeDeclRefExpr The visit callback implementations for the 3 C++ AST Node added to the ASTImporter. Differential Revision: https://reviews.llvm.org/D38845 llvm-svn: 331630
2018-05-07 20:08:27 +08:00
const internal::VariadicDynCastAllOfMatcher<Expr, DependentScopeDeclRefExpr>
dependentScopeDeclRefExpr;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, DependentScopeDeclRefExpr) {
[ASTImporter] Support importing UnresolvedMemberExpr, DependentNameType, DependentScopeDeclRefExpr The visit callback implementations for the 3 C++ AST Node added to the ASTImporter. Differential Revision: https://reviews.llvm.org/D38845 llvm-svn: 331630
2018-05-07 20:08:27 +08:00
MatchVerifier<Decl> Verifier;
testImport("template <typename T> struct S { static T foo; };"
"template <typename T> void declToImport() {"
" (void) S<T>::foo;"
"}"
[ASTImporter] Eliminated some unittest warnings. 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
2018-06-29 18:25:19 +08:00
"void instantiate() { declToImport<int>(); }"
"template <typename T> T S<T>::foo;",
[ASTImporter] Support importing UnresolvedMemberExpr, DependentNameType, DependentScopeDeclRefExpr The visit callback implementations for the 3 C++ AST Node added to the ASTImporter. Differential Revision: https://reviews.llvm.org/D38845 llvm-svn: 331630
2018-05-07 20:08:27 +08:00
Lang_CXX11, "", Lang_CXX11, Verifier,
functionTemplateDecl(has(functionDecl(has(compoundStmt(
has(cStyleCastExpr(has(dependentScopeDeclRefExpr())))))))));
testImport("template <typename T> struct S {"
"template<typename S> static void foo(){};"
"};"
"template <typename T> void declToImport() {"
" S<T>::template foo<T>();"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX11, "", Lang_CXX11, Verifier,
functionTemplateDecl(has(functionDecl(has(compoundStmt(
has(callExpr(has(dependentScopeDeclRefExpr())))))))));
}
const internal::VariadicDynCastAllOfMatcher<Type, DependentNameType>
dependentNameType;
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, DependentNameType) {
[ASTImporter] Support importing UnresolvedMemberExpr, DependentNameType, DependentScopeDeclRefExpr The visit callback implementations for the 3 C++ AST Node added to the ASTImporter. Differential Revision: https://reviews.llvm.org/D38845 llvm-svn: 331630
2018-05-07 20:08:27 +08:00
MatchVerifier<Decl> Verifier;
testImport("template <typename T> struct declToImport {"
" typedef typename T::type dependent_name;"
"};",
Lang_CXX11, "", Lang_CXX11, Verifier,
classTemplateDecl(has(
cxxRecordDecl(has(typedefDecl(has(dependentNameType())))))));
}
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
TEST_P(ImportExpr, UnresolvedMemberExpr) {
[ASTImporter] Support importing UnresolvedMemberExpr, DependentNameType, DependentScopeDeclRefExpr The visit callback implementations for the 3 C++ AST Node added to the ASTImporter. Differential Revision: https://reviews.llvm.org/D38845 llvm-svn: 331630
2018-05-07 20:08:27 +08:00
MatchVerifier<Decl> Verifier;
testImport("struct S { template <typename T> void mem(); };"
"template <typename U> void declToImport() {"
" S s;"
" s.mem<U>();"
"}"
"void instantiate() { declToImport<int>(); }",
Lang_CXX11, "", Lang_CXX11, Verifier,
functionTemplateDecl(has(functionDecl(has(
compoundStmt(has(callExpr(has(unresolvedMemberExpr())))))))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
class ImportImplicitMethods : public ASTImporterOptionSpecificTestBase {
[ASTImporter] Import implicit methods of existing class. 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
2018-07-16 20:16:39 +08:00
public:
static constexpr auto DefaultCode = R"(
struct A { int x; };
void f() {
A a;
A a1(a);
A a2(A{});
a = a1;
a = A{};
a.~A();
})";
template <typename MatcherType>
void testImportOf(
const MatcherType &MethodMatcher, const char *Code = DefaultCode) {
test(MethodMatcher, Code, /*ExpectedCount=*/1u);
}
template <typename MatcherType>
void testNoImportOf(
const MatcherType &MethodMatcher, const char *Code = DefaultCode) {
test(MethodMatcher, Code, /*ExpectedCount=*/0u);
}
private:
template <typename MatcherType>
void test(const MatcherType &MethodMatcher,
const char *Code, unsigned int ExpectedCount) {
auto ClassMatcher = cxxRecordDecl(unless(isImplicit()));
Decl *ToTU = getToTuDecl(Code, Lang_CXX11);
auto *ToClass = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, ClassMatcher);
[ASTImporter] Changed constant int to unsigned int in test code. llvm-svn: 337172
2018-07-16 22:05:18 +08:00
ASSERT_EQ(DeclCounter<CXXMethodDecl>().match(ToClass, MethodMatcher), 1u);
[ASTImporter] Import implicit methods of existing class. 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
2018-07-16 20:16:39 +08:00
{
CXXMethodDecl *Method =
FirstDeclMatcher<CXXMethodDecl>().match(ToClass, MethodMatcher);
ToClass->removeDecl(Method);
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
SharedStatePtr->getLookupTable()->remove(Method);
[ASTImporter] Import implicit methods of existing class. 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
2018-07-16 20:16:39 +08:00
}
[ASTImporter] Changed constant int to unsigned int in test code. llvm-svn: 337172
2018-07-16 22:05:18 +08:00
ASSERT_EQ(DeclCounter<CXXMethodDecl>().match(ToClass, MethodMatcher), 0u);
[ASTImporter] Import implicit methods of existing class. 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
2018-07-16 20:16:39 +08:00
Decl *ImportedClass = nullptr;
{
Decl *FromTU = getTuDecl(Code, Lang_CXX11, "input1.cc");
auto *FromClass = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, ClassMatcher);
ImportedClass = Import(FromClass, Lang_CXX11);
}
EXPECT_EQ(ToClass, ImportedClass);
EXPECT_EQ(DeclCounter<CXXMethodDecl>().match(ToClass, MethodMatcher),
ExpectedCount);
}
};
TEST_P(ImportImplicitMethods, DefaultConstructor) {
testImportOf(cxxConstructorDecl(isDefaultConstructor()));
}
TEST_P(ImportImplicitMethods, CopyConstructor) {
testImportOf(cxxConstructorDecl(isCopyConstructor()));
}
TEST_P(ImportImplicitMethods, MoveConstructor) {
testImportOf(cxxConstructorDecl(isMoveConstructor()));
}
TEST_P(ImportImplicitMethods, Destructor) {
testImportOf(cxxDestructorDecl());
}
TEST_P(ImportImplicitMethods, CopyAssignment) {
testImportOf(cxxMethodDecl(isCopyAssignmentOperator()));
}
TEST_P(ImportImplicitMethods, MoveAssignment) {
testImportOf(cxxMethodDecl(isMoveAssignmentOperator()));
}
TEST_P(ImportImplicitMethods, DoNotImportUserProvided) {
auto Code = R"(
struct A { A() { int x; } };
)";
testNoImportOf(cxxConstructorDecl(isDefaultConstructor()), Code);
}
TEST_P(ImportImplicitMethods, DoNotImportDefault) {
auto Code = R"(
struct A { A() = default; };
)";
testNoImportOf(cxxConstructorDecl(isDefaultConstructor()), Code);
}
TEST_P(ImportImplicitMethods, DoNotImportDeleted) {
auto Code = R"(
struct A { A() = delete; };
)";
testNoImportOf(cxxConstructorDecl(isDefaultConstructor()), Code);
}
TEST_P(ImportImplicitMethods, DoNotImportOtherMethod) {
auto Code = R"(
struct A { void f() { } };
)";
testNoImportOf(cxxMethodDecl(hasName("f")), Code);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfEquivalentRecord) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToR1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { };", Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromR = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToR1 = Import(FromR, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToR2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { };", Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromR = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToR2 = Import(FromR, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Lift VFS from clang to llvm (NFC) 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
2018-10-10 21:27:25 +08:00
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
EXPECT_EQ(ToR1, ToR2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfNonEquivalentRecord) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToR1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { int x; };", Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromR = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToR1 = Import(FromR, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToR2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("struct A { unsigned x; };", Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromR = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToR2 = Import(FromR, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
EXPECT_NE(ToR1, ToR2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfEquivalentField) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToF1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { int x; };", Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromF = FirstDeclMatcher<FieldDecl>().match(
FromTU, fieldDecl(hasName("x")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToF1 = Import(FromF, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToF2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { int x; };", Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromF = FirstDeclMatcher<FieldDecl>().match(
FromTU, fieldDecl(hasName("x")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToF2 = Import(FromF, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
EXPECT_EQ(ToF1, ToF2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfNonEquivalentField) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToF1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { int x; };", Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromF = FirstDeclMatcher<FieldDecl>().match(
FromTU, fieldDecl(hasName("x")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToF1 = Import(FromF, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToF2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("struct A { unsigned x; };", Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromF = FirstDeclMatcher<FieldDecl>().match(
FromTU, fieldDecl(hasName("x")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToF2 = Import(FromF, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
EXPECT_NE(ToF1, ToF2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfEquivalentMethod) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToM1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { void x(); }; void A::x() { }",
Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromM = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("x"), isDefinition()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToM1 = Import(FromM, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToM2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { void x(); }; void A::x() { }",
Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromM = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("x"), isDefinition()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToM2 = Import(FromM, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
EXPECT_EQ(ToM1, ToM2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfNonEquivalentMethod) {
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
Decl *ToM1;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("struct A { void x(); }; void A::x() { }",
Lang_CXX03, "input0.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromM = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("x"), isDefinition()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToM1 = Import(FromM, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
Decl *ToM2;
{
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU =
getTuDecl("struct A { void x() const; }; void A::x() const { }",
Lang_CXX03, "input1.cc");
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
auto *FromM = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("x"), isDefinition()));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ToM2 = Import(FromM, Lang_CXX03);
[AST] Structural equivalence of methods Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
2018-07-11 17:37:24 +08:00
}
EXPECT_NE(ToM1, ToM2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportUnnamedStructsWithRecursingField) {
[ASTImporter] Fix import of unnamed structs 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
2018-07-17 20:06:36 +08:00
Decl *FromTU = getTuDecl(
R"(
struct A {
struct {
struct A *next;
} entry0;
struct {
struct A *next;
} entry1;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99, "input0.cc");
[ASTImporter] Fix import of unnamed structs 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
2018-07-17 20:06:36 +08:00
auto *From =
FirstDeclMatcher<RecordDecl>().match(FromTU, recordDecl(hasName("A")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(From, Lang_C99);
[ASTImporter] Fix import of unnamed structs 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
2018-07-17 20:06:36 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
auto *Entry0 =
FirstDeclMatcher<FieldDecl>().match(ToTU, fieldDecl(hasName("entry0")));
auto *Entry1 =
FirstDeclMatcher<FieldDecl>().match(ToTU, fieldDecl(hasName("entry1")));
auto *R0 = getRecordDecl(Entry0);
auto *R1 = getRecordDecl(Entry1);
EXPECT_NE(R0, R1);
EXPECT_TRUE(MatchVerifier<RecordDecl>().match(
R0, recordDecl(has(fieldDecl(hasName("next"))))));
EXPECT_TRUE(MatchVerifier<RecordDecl>().match(
R1, recordDecl(has(fieldDecl(hasName("next"))))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportUnnamedFieldsInCorrectOrder) {
[ASTImporter] Load external Decls when getting field index. 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
2018-08-08 17:40:57 +08:00
Decl *FromTU = getTuDecl(
R"(
void f(int X, int Y, bool Z) {
(void)[X, Y, Z] { (void)Z; };
}
)",
Lang_CXX11, "input0.cc");
auto *FromF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
auto *ToF = cast_or_null<FunctionDecl>(Import(FromF, Lang_CXX11));
EXPECT_TRUE(ToF);
CXXRecordDecl *FromLambda =
cast<LambdaExpr>(cast<CStyleCastExpr>(cast<CompoundStmt>(
FromF->getBody())->body_front())->getSubExpr())->getLambdaClass();
auto *ToLambda = cast_or_null<CXXRecordDecl>(Import(FromLambda, Lang_CXX11));
EXPECT_TRUE(ToLambda);
// Check if the fields of the lambda class are imported in correct order.
unsigned FromIndex = 0u;
for (auto *FromField : FromLambda->fields()) {
ASSERT_FALSE(FromField->getDeclName());
auto *ToField = cast_or_null<FieldDecl>(Import(FromField, Lang_CXX11));
EXPECT_TRUE(ToField);
[ASTImporter] Added error handling for AST import. 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
2018-10-19 21:32:20 +08:00
Optional<unsigned> ToIndex = ASTImporter::getFieldIndex(ToField);
EXPECT_TRUE(ToIndex);
EXPECT_EQ(*ToIndex, FromIndex);
[ASTImporter] Load external Decls when getting field index. 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
2018-08-08 17:40:57 +08:00
++FromIndex;
}
EXPECT_EQ(FromIndex, 3u);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
MergeFieldDeclsOfClassTemplateSpecialization) {
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
std::string ClassTemplate =
R"(
template <typename T>
struct X {
int a{0}; // FieldDecl with InitListExpr
X(char) : a(3) {} // (1)
X(int) {} // (2)
};
)";
Decl *ToTU = getToTuDecl(ClassTemplate +
R"(
void foo() {
// ClassTemplateSpec with ctor (1): FieldDecl without InitlistExpr
X<char> xc('c');
}
)", Lang_CXX11);
auto *ToSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X")));
// FieldDecl without InitlistExpr:
auto *ToField = *ToSpec->field_begin();
ASSERT_TRUE(ToField);
ASSERT_FALSE(ToField->getInClassInitializer());
Decl *FromTU = getTuDecl(ClassTemplate +
R"(
void bar() {
// ClassTemplateSpec with ctor (2): FieldDecl WITH InitlistExpr
X<char> xc(1);
}
)", Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("X")));
// FieldDecl with InitlistExpr:
auto *FromField = *FromSpec->field_begin();
ASSERT_TRUE(FromField);
ASSERT_TRUE(FromField->getInClassInitializer());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
ASSERT_TRUE(ImportedSpec);
EXPECT_EQ(ImportedSpec, ToSpec);
// After the import, the FieldDecl has to be merged, thus it should have the
// InitListExpr.
EXPECT_TRUE(ToField->getInClassInitializer());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
MergeFunctionOfClassTemplateSpecialization) {
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
std::string ClassTemplate =
R"(
template <typename T>
struct X {
void f() {}
void g() {}
};
)";
Decl *ToTU = getToTuDecl(ClassTemplate +
R"(
void foo() {
X<char> x;
x.f();
}
)", Lang_CXX11);
Decl *FromTU = getTuDecl(ClassTemplate +
R"(
void bar() {
X<char> x;
x.g();
}
)", Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("X")));
auto FunPattern = functionDecl(hasName("g"),
hasParent(classTemplateSpecializationDecl()));
auto *FromFun =
FirstDeclMatcher<FunctionDecl>().match(FromTU, FunPattern);
auto *ToFun =
FirstDeclMatcher<FunctionDecl>().match(ToTU, FunPattern);
ASSERT_TRUE(FromFun->hasBody());
ASSERT_FALSE(ToFun->hasBody());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
ASSERT_TRUE(ImportedSpec);
auto *ToSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X")));
EXPECT_EQ(ImportedSpec, ToSpec);
EXPECT_TRUE(ToFun->hasBody());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
ODRViolationOfClassTemplateSpecializationsShouldBeReported) {
std::string ClassTemplate =
R"(
template <typename T>
struct X {};
)";
Decl *ToTU = getToTuDecl(ClassTemplate +
R"(
template <>
struct X<char> {
int a;
};
void foo() {
X<char> x;
}
)",
Lang_CXX11);
Decl *FromTU = getTuDecl(ClassTemplate +
R"(
template <>
struct X<char> {
int b;
};
void foo() {
X<char> x;
}
)",
Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("X")));
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
// We expect one (ODR) warning during the import.
EXPECT_EQ(1u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
// The second specialization is different from the first, thus it violates
// ODR, consequently we expect to keep the first specialization only, which is
// already in the "To" context.
[ASTImporter] Fix redecl failures of ClassTemplateSpec 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
2019-03-19 21:34:10 +08:00
EXPECT_FALSE(ImportedSpec);
EXPECT_EQ(1u,
DeclCounter<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X"))));
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
MergeCtorOfClassTemplateSpecialization) {
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
std::string ClassTemplate =
R"(
template <typename T>
struct X {
X(char) {}
X(int) {}
};
)";
Decl *ToTU = getToTuDecl(ClassTemplate +
R"(
void foo() {
X<char> x('c');
}
)", Lang_CXX11);
Decl *FromTU = getTuDecl(ClassTemplate +
R"(
void bar() {
X<char> x(1);
}
)", Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("X")));
// Match the void(int) ctor.
auto CtorPattern =
cxxConstructorDecl(hasParameter(0, varDecl(hasType(asString("int")))),
hasParent(classTemplateSpecializationDecl()));
auto *FromCtor =
FirstDeclMatcher<CXXConstructorDecl>().match(FromTU, CtorPattern);
auto *ToCtor =
FirstDeclMatcher<CXXConstructorDecl>().match(ToTU, CtorPattern);
ASSERT_TRUE(FromCtor->hasBody());
ASSERT_FALSE(ToCtor->hasBody());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
ASSERT_TRUE(ImportedSpec);
auto *ToSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X")));
EXPECT_EQ(ImportedSpec, ToSpec);
EXPECT_TRUE(ToCtor->hasBody());
}
[ASTImporter] Add unittest case for friend decl import Summary: This change adds a matching test case for the recent bug fix to VisitFriendDecl in ASTImporterLookup.cpp. See https://reviews.llvm.org/D82882 for details. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, teemperor, cfe-commits, dkrupp Tags: #clang Differential Revision: https://reviews.llvm.org/D83006
2020-07-02 05:49:08 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ClassTemplateFriendDecl) {
const auto *Code =
R"(
template <class T> class X { friend T; };
struct Y {};
template class X<Y>;
)";
Decl *ToTU = getToTuDecl(Code, Lang_CXX11);
Decl *FromTU = getTuDecl(Code, Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl());
auto *ToSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
EXPECT_EQ(ImportedSpec, ToSpec);
EXPECT_EQ(1u, DeclCounter<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl()));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
ClassTemplatePartialSpecializationsShouldNotBeDuplicated) {
auto Code =
R"(
// primary template
template<class T1, class T2, int I>
class A {};
// partial specialization
template<class T, int I>
class A<T, T*, I> {};
)";
Decl *ToTU = getToTuDecl(Code, Lang_CXX11);
Decl *FromTU = getTuDecl(Code, Lang_CXX11);
auto *FromSpec =
FirstDeclMatcher<ClassTemplatePartialSpecializationDecl>().match(
FromTU, classTemplatePartialSpecializationDecl());
auto *ToSpec =
FirstDeclMatcher<ClassTemplatePartialSpecializationDecl>().match(
ToTU, classTemplatePartialSpecializationDecl());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
EXPECT_EQ(ImportedSpec, ToSpec);
EXPECT_EQ(1u, DeclCounter<ClassTemplatePartialSpecializationDecl>().match(
ToTU, classTemplatePartialSpecializationDecl()));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ClassTemplateSpecializationsShouldNotBeDuplicated) {
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
auto Code =
R"(
// primary template
template<class T1, class T2, int I>
class A {};
// full specialization
template<>
class A<int, int, 1> {};
)";
Decl *ToTU = getToTuDecl(Code, Lang_CXX11);
Decl *FromTU = getTuDecl(Code, Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl());
auto *ToSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
EXPECT_EQ(ImportedSpec, ToSpec);
EXPECT_EQ(1u, DeclCounter<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl()));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ClassTemplateFullAndPartialSpecsShouldNotBeMixed) {
Fix import of class templates partial specialization 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
2018-08-22 19:52:14 +08:00
std::string PrimaryTemplate =
R"(
template<class T1, class T2, int I>
class A {};
)";
auto PartialSpec =
R"(
template<class T, int I>
class A<T, T*, I> {};
)";
auto FullSpec =
R"(
template<>
class A<int, int, 1> {};
)";
Decl *ToTU = getToTuDecl(PrimaryTemplate + FullSpec, Lang_CXX11);
Decl *FromTU = getTuDecl(PrimaryTemplate + PartialSpec, Lang_CXX11);
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl());
auto *ImportedSpec = Import(FromSpec, Lang_CXX11);
EXPECT_TRUE(ImportedSpec);
// Check the number of partial specializations.
EXPECT_EQ(1u, DeclCounter<ClassTemplatePartialSpecializationDecl>().match(
ToTU, classTemplatePartialSpecializationDecl()));
// Check the number of full specializations.
EXPECT_EQ(1u, DeclCounter<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(
unless(classTemplatePartialSpecializationDecl()))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
InitListExprValueKindShouldBeImported) {
[ASTImporter] Merge ExprBits 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
2018-09-03 21:10:53 +08:00
Decl *TU = getTuDecl(
R"(
const int &init();
void foo() { const int &a{init()}; }
)", Lang_CXX11, "input0.cc");
auto *FromD = FirstDeclMatcher<VarDecl>().match(TU, varDecl(hasName("a")));
ASSERT_TRUE(FromD->getAnyInitializer());
auto *InitExpr = FromD->getAnyInitializer();
ASSERT_TRUE(InitExpr);
ASSERT_TRUE(InitExpr->isGLValue());
auto *ToD = Import(FromD, Lang_CXX11);
EXPECT_TRUE(ToD);
auto *ToInitExpr = cast<VarDecl>(ToD)->getAnyInitializer();
EXPECT_TRUE(ToInitExpr);
EXPECT_TRUE(ToInitExpr->isGLValue());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ImportVariables : ASTImporterOptionSpecificTestBase {};
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
TEST_P(ImportVariables, ImportOfOneDeclBringsInTheWholeChain) {
Decl *FromTU = getTuDecl(
R"(
struct A {
static const int a = 1 + 2;
};
const int A::a;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
)",
Lang_CXX03, "input1.cc");
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto *FromDWithInit = FirstDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a"))); // Decl with init
auto *FromDWithDef = LastDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a"))); // Decl with definition
ASSERT_NE(FromDWithInit, FromDWithDef);
ASSERT_EQ(FromDWithDef->getPreviousDecl(), FromDWithInit);
auto *ToD0 = cast<VarDecl>(Import(FromDWithInit, Lang_CXX11));
auto *ToD1 = cast<VarDecl>(Import(FromDWithDef, Lang_CXX11));
ASSERT_TRUE(ToD0);
ASSERT_TRUE(ToD1);
EXPECT_NE(ToD0, ToD1);
EXPECT_EQ(ToD1->getPreviousDecl(), ToD0);
}
TEST_P(ImportVariables, InitAndDefinitionAreInDifferentTUs) {
auto StructA =
R"(
struct A {
static const int a = 1 + 2;
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTU = getToTuDecl(StructA, Lang_CXX03);
Decl *FromTU = getTuDecl(std::string(StructA) + "const int A::a;", Lang_CXX03,
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
"input1.cc");
auto *FromDWithInit = FirstDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a"))); // Decl with init
auto *FromDWithDef = LastDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a"))); // Decl with definition
ASSERT_EQ(FromDWithInit, FromDWithDef->getPreviousDecl());
ASSERT_TRUE(FromDWithInit->getInit());
ASSERT_FALSE(FromDWithInit->isThisDeclarationADefinition());
ASSERT_TRUE(FromDWithDef->isThisDeclarationADefinition());
ASSERT_FALSE(FromDWithDef->getInit());
auto *ToD = FirstDeclMatcher<VarDecl>().match(
ToTU, varDecl(hasName("a"))); // Decl with init
ASSERT_TRUE(ToD->getInit());
ASSERT_FALSE(ToD->getDefinition());
auto *ImportedD = cast<VarDecl>(Import(FromDWithDef, Lang_CXX11));
EXPECT_TRUE(ImportedD->getAnyInitializer());
EXPECT_TRUE(ImportedD->getDefinition());
}
TEST_P(ImportVariables, InitAndDefinitionAreInTheFromContext) {
auto StructA =
R"(
struct A {
static const int a;
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTU = getToTuDecl(StructA, Lang_CXX03);
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
Decl *FromTU = getTuDecl(std::string(StructA) + "const int A::a = 1 + 2;",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
auto *FromDDeclarationOnly = FirstDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a")));
auto *FromDWithDef = LastDeclMatcher<VarDecl>().match(
FromTU, varDecl(hasName("a"))); // Decl with definition and with init.
ASSERT_EQ(FromDDeclarationOnly, FromDWithDef->getPreviousDecl());
ASSERT_FALSE(FromDDeclarationOnly->getInit());
ASSERT_FALSE(FromDDeclarationOnly->isThisDeclarationADefinition());
ASSERT_TRUE(FromDWithDef->isThisDeclarationADefinition());
ASSERT_TRUE(FromDWithDef->getInit());
auto *ToD = FirstDeclMatcher<VarDecl>().match(
ToTU, varDecl(hasName("a")));
ASSERT_FALSE(ToD->getInit());
ASSERT_FALSE(ToD->getDefinition());
auto *ImportedD = cast<VarDecl>(Import(FromDWithDef, Lang_CXX11));
EXPECT_TRUE(ImportedD->getAnyInitializer());
EXPECT_TRUE(ImportedD->getDefinition());
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ImportClasses : ASTImporterOptionSpecificTestBase {};
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
TEST_P(ImportClasses, ImportDefinitionWhenProtoIsInNestedToContext) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTU = getToTuDecl("struct A { struct X *Xp; };", Lang_C99);
Decl *FromTU1 = getTuDecl("struct X {};", Lang_C99, "input1.cc");
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto Pattern = recordDecl(hasName("X"), unless(isImplicit()));
auto ToProto = FirstDeclMatcher<RecordDecl>().match(ToTU, Pattern);
auto FromDef = FirstDeclMatcher<RecordDecl>().match(FromTU1, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ImportedDef = Import(FromDef, Lang_C99);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
EXPECT_NE(ImportedDef, ToProto);
EXPECT_EQ(DeclCounter<RecordDecl>().match(ToTU, Pattern), 2u);
auto ToDef = LastDeclMatcher<RecordDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ImportedDef == ToDef);
EXPECT_TRUE(ToDef->isThisDeclarationADefinition());
EXPECT_FALSE(ToProto->isThisDeclarationADefinition());
EXPECT_EQ(ToDef->getPreviousDecl(), ToProto);
}
TEST_P(ImportClasses, ImportDefinitionWhenProtoIsInNestedToContextCXX) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ToTU = getToTuDecl("struct A { struct X *Xp; };", Lang_CXX03);
Decl *FromTU1 = getTuDecl("struct X {};", Lang_CXX03, "input1.cc");
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto Pattern = recordDecl(hasName("X"), unless(isImplicit()));
auto ToProto = FirstDeclMatcher<RecordDecl>().match(ToTU, Pattern);
auto FromDef = FirstDeclMatcher<RecordDecl>().match(FromTU1, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ImportedDef = Import(FromDef, Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
EXPECT_NE(ImportedDef, ToProto);
EXPECT_EQ(DeclCounter<RecordDecl>().match(ToTU, Pattern), 2u);
auto ToDef = LastDeclMatcher<RecordDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ImportedDef == ToDef);
EXPECT_TRUE(ToDef->isThisDeclarationADefinition());
EXPECT_FALSE(ToProto->isThisDeclarationADefinition());
EXPECT_EQ(ToDef->getPreviousDecl(), ToProto);
}
TEST_P(ImportClasses, ImportNestedPrototypeThenDefinition) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU0 =
getTuDecl("struct A { struct X *Xp; };", Lang_C99, "input0.cc");
Decl *FromTU1 = getTuDecl("struct X {};", Lang_C99, "input1.cc");
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto Pattern = recordDecl(hasName("X"), unless(isImplicit()));
auto FromProto = FirstDeclMatcher<RecordDecl>().match(FromTU0, Pattern);
auto FromDef = FirstDeclMatcher<RecordDecl>().match(FromTU1, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *ImportedProto = Import(FromProto, Lang_C99);
Decl *ImportedDef = Import(FromDef, Lang_C99);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
Decl *ToTU = ImportedDef->getTranslationUnitDecl();
EXPECT_NE(ImportedDef, ImportedProto);
EXPECT_EQ(DeclCounter<RecordDecl>().match(ToTU, Pattern), 2u);
auto ToProto = FirstDeclMatcher<RecordDecl>().match(ToTU, Pattern);
auto ToDef = LastDeclMatcher<RecordDecl>().match(ToTU, Pattern);
EXPECT_TRUE(ImportedDef == ToDef);
EXPECT_TRUE(ImportedProto == ToProto);
EXPECT_TRUE(ToDef->isThisDeclarationADefinition());
EXPECT_FALSE(ToProto->isThisDeclarationADefinition());
EXPECT_EQ(ToDef->getPreviousDecl(), ToProto);
}
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ImportFriendClasses : ASTImporterOptionSpecificTestBase {};
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
TEST_P(ImportFriendClasses, ImportOfFriendRecordDoesNotMergeDefinition) {
Decl *FromTU = getTuDecl(
R"(
class A {
template <int I> class F {};
class X {
template <int I> friend class F;
};
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *FromClass = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("F"), isDefinition()));
auto *FromFriendClass = LastDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("F")));
ASSERT_TRUE(FromClass);
ASSERT_TRUE(FromFriendClass);
ASSERT_NE(FromClass, FromFriendClass);
ASSERT_EQ(FromFriendClass->getDefinition(), FromClass);
ASSERT_EQ(FromFriendClass->getPreviousDecl(), FromClass);
ASSERT_EQ(FromFriendClass->getDescribedClassTemplate()->getPreviousDecl(),
FromClass->getDescribedClassTemplate());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToClass = cast<CXXRecordDecl>(Import(FromClass, Lang_CXX03));
auto *ToFriendClass =
cast<CXXRecordDecl>(Import(FromFriendClass, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
EXPECT_TRUE(ToClass);
EXPECT_TRUE(ToFriendClass);
EXPECT_NE(ToClass, ToFriendClass);
EXPECT_EQ(ToFriendClass->getDefinition(), ToClass);
EXPECT_EQ(ToFriendClass->getPreviousDecl(), ToClass);
EXPECT_EQ(ToFriendClass->getDescribedClassTemplate()->getPreviousDecl(),
ToClass->getDescribedClassTemplate());
}
TEST_P(ImportFriendClasses, ImportOfRecursiveFriendClass) {
Decl *FromTu = getTuDecl(
R"(
class declToImport {
friend class declToImport;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *FromD = FirstDeclMatcher<CXXRecordDecl>().match(
FromTu, cxxRecordDecl(hasName("declToImport")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto Pattern = cxxRecordDecl(has(friendDecl()));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(FromD, Pattern));
EXPECT_TRUE(MatchVerifier<Decl>{}.match(ToD, Pattern));
}
recommit: [ASTImporter] Friend class decl should not be visible in its context Summary: In the past we had to use DeclContext::makeDeclVisibleInContext to make friend declarations available for subsequent lookup calls and this way we could chain (redecl) the structurally equivalent decls. By doing this we created an AST that improperly made declarations visible in some contexts, so the AST was malformed. Since we use the importer specific lookup this is no longer necessary, because with that we can find every previous nodes. Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71020
2019-12-05 00:12:08 +08:00
TEST_P(ImportFriendClasses, UndeclaredFriendClassShouldNotBeVisible) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTu =
getTuDecl("class X { friend class Y; };", Lang_CXX03, "from.cc");
recommit: [ASTImporter] Friend class decl should not be visible in its context Summary: In the past we had to use DeclContext::makeDeclVisibleInContext to make friend declarations available for subsequent lookup calls and this way we could chain (redecl) the structurally equivalent decls. By doing this we created an AST that improperly made declarations visible in some contexts, so the AST was malformed. Since we use the importer specific lookup this is no longer necessary, because with that we can find every previous nodes. Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71020
2019-12-05 00:12:08 +08:00
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTu, cxxRecordDecl(hasName("X")));
auto *FromFriend = FirstDeclMatcher<FriendDecl>().match(FromTu, friendDecl());
RecordDecl *FromRecordOfFriend =
const_cast<RecordDecl *>(getRecordDeclOfFriend(FromFriend));
ASSERT_EQ(FromRecordOfFriend->getDeclContext(), cast<DeclContext>(FromTu));
ASSERT_EQ(FromRecordOfFriend->getLexicalDeclContext(),
cast<DeclContext>(FromX));
ASSERT_FALSE(
FromRecordOfFriend->getDeclContext()->containsDecl(FromRecordOfFriend));
ASSERT_FALSE(FromRecordOfFriend->getLexicalDeclContext()->containsDecl(
FromRecordOfFriend));
ASSERT_FALSE(FromRecordOfFriend->getLookupParent()
->lookup(FromRecordOfFriend->getDeclName())
.empty());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToX = Import(FromX, Lang_CXX03);
recommit: [ASTImporter] Friend class decl should not be visible in its context Summary: In the past we had to use DeclContext::makeDeclVisibleInContext to make friend declarations available for subsequent lookup calls and this way we could chain (redecl) the structurally equivalent decls. By doing this we created an AST that improperly made declarations visible in some contexts, so the AST was malformed. Since we use the importer specific lookup this is no longer necessary, because with that we can find every previous nodes. Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D71020
2019-12-05 00:12:08 +08:00
ASSERT_TRUE(ToX);
Decl *ToTu = ToX->getTranslationUnitDecl();
auto *ToFriend = FirstDeclMatcher<FriendDecl>().match(ToTu, friendDecl());
RecordDecl *ToRecordOfFriend =
const_cast<RecordDecl *>(getRecordDeclOfFriend(ToFriend));
ASSERT_EQ(ToRecordOfFriend->getDeclContext(), cast<DeclContext>(ToTu));
ASSERT_EQ(ToRecordOfFriend->getLexicalDeclContext(), cast<DeclContext>(ToX));
EXPECT_FALSE(
ToRecordOfFriend->getDeclContext()->containsDecl(ToRecordOfFriend));
EXPECT_FALSE(ToRecordOfFriend->getLexicalDeclContext()->containsDecl(
ToRecordOfFriend));
EXPECT_FALSE(ToRecordOfFriend->getLookupParent()
->lookup(ToRecordOfFriend->getDeclName())
.empty());
}
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
TEST_P(ImportFriendClasses, ImportOfRecursiveFriendClassTemplate) {
Decl *FromTu = getTuDecl(
R"(
template<class A> class declToImport {
template<class A1> friend class declToImport;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *FromD =
FirstDeclMatcher<ClassTemplateDecl>().match(FromTu, classTemplateDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto Pattern = classTemplateDecl(
has(cxxRecordDecl(has(friendDecl(has(classTemplateDecl()))))));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(FromD, Pattern));
EXPECT_TRUE(MatchVerifier<Decl>{}.match(ToD, Pattern));
auto *Class =
FirstDeclMatcher<ClassTemplateDecl>().match(ToD, classTemplateDecl());
auto *Friend = FirstDeclMatcher<FriendDecl>().match(ToD, friendDecl());
EXPECT_NE(Friend->getFriendDecl(), Class);
EXPECT_EQ(Friend->getFriendDecl()->getPreviousDecl(), Class);
}
TEST_P(ImportFriendClasses, ProperPrevDeclForClassTemplateDecls) {
auto Pattern = classTemplateSpecializationDecl(hasName("X"));
ClassTemplateSpecializationDecl *Imported1;
{
Decl *FromTU = getTuDecl("template<class T> class X;"
"struct Y { friend class X<int>; };",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *FromD = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Imported1 =
cast<ClassTemplateSpecializationDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
}
ClassTemplateSpecializationDecl *Imported2;
{
Decl *FromTU = getTuDecl("template<class T> class X;"
"template<> class X<int>{};"
"struct Z { friend class X<int>; };",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *FromD = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Imported2 =
cast<ClassTemplateSpecializationDecl>(Import(FromD, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
}
Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<ClassTemplateSpecializationDecl>().match(ToTU, Pattern),
2u);
ASSERT_TRUE(Imported2->getPreviousDecl());
EXPECT_EQ(Imported2->getPreviousDecl(), Imported1);
}
TEST_P(ImportFriendClasses, TypeForDeclShouldBeSetInTemplated) {
Decl *FromTU0 = getTuDecl(
R"(
class X {
class Y;
};
class X::Y {
template <typename T>
friend class F; // The decl context of F is the global namespace.
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Fwd = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU0, classTemplateDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *Imported0 = cast<ClassTemplateDecl>(Import(Fwd, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Decl *FromTU1 = getTuDecl(
R"(
template <typename T>
class F {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Definition = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU1, classTemplateDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *Imported1 = cast<ClassTemplateDecl>(Import(Definition, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
EXPECT_EQ(Imported0->getTemplatedDecl()->getTypeForDecl(),
Imported1->getTemplatedDecl()->getTypeForDecl());
}
TEST_P(ImportFriendClasses, DeclsFromFriendsShouldBeInRedeclChains) {
Decl *From, *To;
std::tie(From, To) =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getImportedDecl("class declToImport {};", Lang_CXX03,
"class Y { friend class declToImport; };", Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Imported = cast<CXXRecordDecl>(To);
EXPECT_TRUE(Imported->getPreviousDecl());
}
TEST_P(ImportFriendClasses,
ImportOfClassTemplateDefinitionShouldConnectToFwdFriend) {
Decl *ToTU = getToTuDecl(
R"(
class X {
class Y;
};
class X::Y {
template <typename T>
friend class F; // The decl context of F is the global namespace.
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *ToDecl = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("F")));
Decl *FromTU = getTuDecl(
R"(
template <typename T>
class F {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Definition = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedDef = cast<ClassTemplateDecl>(Import(Definition, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
EXPECT_TRUE(ImportedDef->getPreviousDecl());
EXPECT_EQ(ToDecl, ImportedDef->getPreviousDecl());
EXPECT_EQ(ToDecl->getTemplatedDecl(),
ImportedDef->getTemplatedDecl()->getPreviousDecl());
}
TEST_P(ImportFriendClasses,
ImportOfClassTemplateDefinitionAndFwdFriendShouldBeLinked) {
Decl *FromTU0 = getTuDecl(
R"(
class X {
class Y;
};
class X::Y {
template <typename T>
friend class F; // The decl context of F is the global namespace.
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Fwd = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU0, classTemplateDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedFwd = cast<ClassTemplateDecl>(Import(Fwd, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Decl *FromTU1 = getTuDecl(
R"(
template <typename T>
class F {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Definition = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU1, classTemplateDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedDef = cast<ClassTemplateDecl>(Import(Definition, Lang_CXX03));
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
EXPECT_TRUE(ImportedDef->getPreviousDecl());
EXPECT_EQ(ImportedFwd, ImportedDef->getPreviousDecl());
EXPECT_EQ(ImportedFwd->getTemplatedDecl(),
ImportedDef->getTemplatedDecl()->getPreviousDecl());
}
TEST_P(ImportFriendClasses, ImportOfClassDefinitionAndFwdFriendShouldBeLinked) {
Decl *FromTU0 = getTuDecl(
R"(
class X {
class Y;
};
class X::Y {
friend class F; // The decl context of F is the global namespace.
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Friend = FirstDeclMatcher<FriendDecl>().match(FromTU0, friendDecl());
QualType FT = Friend->getFriendType()->getType();
FT = FromTU0->getASTContext().getCanonicalType(FT);
auto *Fwd = cast<TagType>(FT)->getDecl();
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedFwd = Import(Fwd, Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
Decl *FromTU1 = getTuDecl(
R"(
class F {};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *Definition = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU1, cxxRecordDecl(hasName("F")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedDef = Import(Definition, Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
EXPECT_TRUE(ImportedDef->getPreviousDecl());
EXPECT_EQ(ImportedFwd, ImportedDef->getPreviousDecl());
}
[ASTImporter] Corrected import of repeated friend declarations. Summary: Import declarations in correct order if a class contains multiple redundant friend (type or decl) declarations. If the order is incorrect this could cause false structural equivalences and wrong declaration chains after import. Reviewers: a.sidorin, shafik, a_sidorin Reviewed By: shafik Subscribers: dkrupp, Szelethus, gamesh411, teemperor, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75740
2020-07-07 20:21:18 +08:00
TEST_P(ImportFriendClasses, ImportOfRepeatedFriendType) {
const char *Code =
R"(
class Container {
friend class X;
friend class X;
};
)";
Decl *ToTu = getToTuDecl(Code, Lang_CXX03);
Decl *FromTu = getTuDecl(Code, Lang_CXX03, "from.cc");
auto *ToFriend1 = FirstDeclMatcher<FriendDecl>().match(ToTu, friendDecl());
auto *ToFriend2 = LastDeclMatcher<FriendDecl>().match(ToTu, friendDecl());
auto *FromFriend1 =
FirstDeclMatcher<FriendDecl>().match(FromTu, friendDecl());
auto *FromFriend2 = LastDeclMatcher<FriendDecl>().match(FromTu, friendDecl());
FriendDecl *ToImportedFriend1 = Import(FromFriend1, Lang_CXX03);
FriendDecl *ToImportedFriend2 = Import(FromFriend2, Lang_CXX03);
EXPECT_NE(ToImportedFriend1, ToImportedFriend2);
EXPECT_EQ(ToFriend1, ToImportedFriend1);
EXPECT_EQ(ToFriend2, ToImportedFriend2);
}
TEST_P(ImportFriendClasses, ImportOfRepeatedFriendDecl) {
const char *Code =
R"(
class Container {
friend void f();
friend void f();
};
)";
Decl *ToTu = getToTuDecl(Code, Lang_CXX03);
Decl *FromTu = getTuDecl(Code, Lang_CXX03, "from.cc");
auto *ToFriend1 = FirstDeclMatcher<FriendDecl>().match(ToTu, friendDecl());
auto *ToFriend2 = LastDeclMatcher<FriendDecl>().match(ToTu, friendDecl());
auto *FromFriend1 =
FirstDeclMatcher<FriendDecl>().match(FromTu, friendDecl());
auto *FromFriend2 = LastDeclMatcher<FriendDecl>().match(FromTu, friendDecl());
FriendDecl *ToImportedFriend1 = Import(FromFriend1, Lang_CXX03);
FriendDecl *ToImportedFriend2 = Import(FromFriend2, Lang_CXX03);
EXPECT_NE(ToImportedFriend1, ToImportedFriend2);
EXPECT_EQ(ToFriend1, ToImportedFriend1);
EXPECT_EQ(ToFriend2, ToImportedFriend2);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, FriendFunInClassTemplate) {
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *Code = R"(
template <class T>
struct X {
friend void foo(){}
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *ToTU = getToTuDecl(Code, Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *ToFoo = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl(Code, Lang_CXX03, "input.cc");
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *FromFoo = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedFoo = Import(FromFoo, Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
EXPECT_EQ(ImportedFoo, ToFoo);
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct DeclContextTest : ASTImporterOptionSpecificTestBase {};
Do not try to remove invisible Decls from DeclContext llvm-svn: 332699
2018-05-18 17:08:47 +08:00
TEST_P(DeclContextTest, removeDeclOfClassTemplateSpecialization) {
Decl *TU = getTuDecl(
R"(
namespace NS {
template <typename T>
struct S {};
template struct S<int>;
inline namespace INS {
template <typename T>
struct S {};
template struct S<int>;
}
}
)", Lang_CXX11, "input0.cc");
auto *NS = FirstDeclMatcher<NamespaceDecl>().match(
TU, namespaceDecl());
auto *Spec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
TU, classTemplateSpecializationDecl());
ASSERT_TRUE(NS->containsDecl(Spec));
NS->removeDecl(Spec);
EXPECT_FALSE(NS->containsDecl(Spec));
}
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
TEST_P(DeclContextTest,
removeDeclShouldNotFailEvenIfWeHaveExternalVisibleStorage) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *TU = getTuDecl("extern int A; int A;", Lang_CXX03);
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
auto *A0 = FirstDeclMatcher<VarDecl>().match(TU, varDecl(hasName("A")));
auto *A1 = LastDeclMatcher<VarDecl>().match(TU, varDecl(hasName("A")));
// Investigate the list.
auto *DC = A0->getDeclContext();
ASSERT_TRUE(DC->containsDecl(A0));
ASSERT_TRUE(DC->containsDecl(A1));
// Investigate the lookup table.
auto *Map = DC->getLookupPtr();
ASSERT_TRUE(Map);
auto I = Map->find(A0->getDeclName());
ASSERT_NE(I, Map->end());
StoredDeclsList &L = I->second;
// The lookup table contains the most recent decl of A.
ASSERT_NE(L.getAsDecl(), A0);
ASSERT_EQ(L.getAsDecl(), A1);
ASSERT_TRUE(L.getAsDecl());
// Simulate the private function DeclContext::reconcileExternalVisibleStorage.
// The point here is to have a Vec with only one element, which is not the
// one we are going to delete from the DC later.
L.setHasExternalDecls();
ASSERT_TRUE(L.getAsVector());
ASSERT_EQ(1u, L.getAsVector()->size());
// This asserts in the old implementation.
DC->removeDecl(A0);
EXPECT_FALSE(DC->containsDecl(A0));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ImportFunctionTemplateSpecializations
: ASTImporterOptionSpecificTestBase {};
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
TEST_P(ImportFunctionTemplateSpecializations,
TUshouldNotContainFunctionTemplateImplicitInstantiation) {
Decl *FromTU = getTuDecl(
R"(
template<class T>
int f() { return 0; }
void foo() { f<int>(); }
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
// Check that the function template instantiation is NOT the child of the TU.
auto Pattern = translationUnitDecl(
unless(has(functionDecl(hasName("f"), isTemplateInstantiation()))));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(FromTU, Pattern));
auto *Foo = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ASSERT_TRUE(Import(Foo, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_TRUE(MatchVerifier<Decl>{}.match(ToTU, Pattern));
}
TEST_P(ImportFunctionTemplateSpecializations,
TUshouldNotContainFunctionTemplateExplicitInstantiation) {
Decl *FromTU = getTuDecl(
R"(
template<class T>
int f() { return 0; }
template int f<int>();
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
// Check that the function template instantiation is NOT the child of the TU.
auto Instantiation = functionDecl(hasName("f"), isTemplateInstantiation());
auto Pattern = translationUnitDecl(unless(has(Instantiation)));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(FromTU, Pattern));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ASSERT_TRUE(Import(FirstDeclMatcher<Decl>().match(FromTU, Instantiation),
Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_TRUE(MatchVerifier<Decl>{}.match(ToTU, Pattern));
}
TEST_P(ImportFunctionTemplateSpecializations,
TUshouldContainFunctionTemplateSpecialization) {
Decl *FromTU = getTuDecl(
R"(
template<class T>
int f() { return 0; }
template <> int f<int>() { return 4; }
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
// Check that the function template specialization is the child of the TU.
auto Specialization =
functionDecl(hasName("f"), isExplicitTemplateSpecialization());
auto Pattern = translationUnitDecl(has(Specialization));
ASSERT_TRUE(MatchVerifier<Decl>{}.match(FromTU, Pattern));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ASSERT_TRUE(Import(FirstDeclMatcher<Decl>().match(FromTU, Specialization),
Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_TRUE(MatchVerifier<Decl>{}.match(ToTU, Pattern));
}
TEST_P(ImportFunctionTemplateSpecializations,
FunctionTemplateSpecializationRedeclChain) {
Decl *FromTU = getTuDecl(
R"(
template<class T>
int f() { return 0; }
template <> int f<int>() { return 4; }
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
auto Spec = functionDecl(hasName("f"), isExplicitTemplateSpecialization(),
hasParent(translationUnitDecl()));
auto *FromSpecD = FirstDeclMatcher<Decl>().match(FromTU, Spec);
{
auto *TU = FromTU;
auto *SpecD = FromSpecD;
auto *TemplateD = FirstDeclMatcher<FunctionTemplateDecl>().match(
TU, functionTemplateDecl());
auto *FirstSpecD = *(TemplateD->spec_begin());
ASSERT_EQ(SpecD, FirstSpecD);
ASSERT_TRUE(SpecD->getPreviousDecl());
ASSERT_FALSE(cast<FunctionDecl>(SpecD->getPreviousDecl())
->doesThisDeclarationHaveABody());
}
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ASSERT_TRUE(Import(FromSpecD, Lang_CXX03));
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
{
auto *TU = ToAST->getASTContext().getTranslationUnitDecl();
auto *SpecD = FirstDeclMatcher<Decl>().match(TU, Spec);
auto *TemplateD = FirstDeclMatcher<FunctionTemplateDecl>().match(
TU, functionTemplateDecl());
auto *FirstSpecD = *(TemplateD->spec_begin());
EXPECT_EQ(SpecD, FirstSpecD);
ASSERT_TRUE(SpecD->getPreviousDecl());
EXPECT_FALSE(cast<FunctionDecl>(SpecD->getPreviousDecl())
->doesThisDeclarationHaveABody());
}
}
TEST_P(ImportFunctionTemplateSpecializations,
MatchNumberOfFunctionTemplateSpecializations) {
Decl *FromTU = getTuDecl(
R"(
template <typename T> constexpr int f() { return 0; }
template <> constexpr int f<int>() { return 4; }
void foo() {
static_assert(f<char>() == 0, "");
static_assert(f<int>() == 4, "");
}
)",
Lang_CXX11, "input0.cc");
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Import(FromD, Lang_CXX11);
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(
DeclCounter<FunctionDecl>().match(FromTU, functionDecl(hasName("f"))),
DeclCounter<FunctionDecl>().match(ToTU, functionDecl(hasName("f"))));
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
ImportShouldNotReportFalseODRErrorWhenRecordIsBeingDefined) {
{
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
auto *FromD = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
}
{
Decl *FromTU = getTuDecl(
R"(
template <typename T>
struct B {
void f();
B* b;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
FunctionDecl *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(FromD, Lang_CXX03);
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
auto *FromCTD = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("B")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToCTD = cast<ClassTemplateDecl>(Import(FromCTD, Lang_CXX03));
[ASTImporter][Structural Eq] Check for isBeingDefined 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
2018-11-26 23:54:08 +08:00
EXPECT_TRUE(ToCTD->isThisDeclarationADefinition());
// We expect no (ODR) warning during the import.
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(0u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
}
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportingTypedefShouldImportTheCompleteType) {
[ASTImporter] Typedef import brings in the complete type 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
2018-11-27 17:51:36 +08:00
// We already have an incomplete underlying type in the "To" context.
auto Code =
R"(
template <typename T>
struct S {
void foo();
};
using U = S<int>;
)";
Decl *ToTU = getToTuDecl(Code, Lang_CXX11);
auto *ToD = FirstDeclMatcher<TypedefNameDecl>().match(ToTU,
typedefNameDecl(hasName("U")));
ASSERT_TRUE(ToD->getUnderlyingType()->isIncompleteType());
// The "From" context has the same typedef, but the underlying type is
// complete this time.
Decl *FromTU = getTuDecl(std::string(Code) +
R"(
void foo(U* u) {
u->foo();
}
)", Lang_CXX11);
auto *FromD = FirstDeclMatcher<TypedefNameDecl>().match(FromTU,
typedefNameDecl(hasName("U")));
ASSERT_FALSE(FromD->getUnderlyingType()->isIncompleteType());
// The imported type should be complete.
auto *ImportedD = cast<TypedefNameDecl>(Import(FromD, Lang_CXX11));
EXPECT_FALSE(ImportedD->getUnderlyingType()->isIncompleteType());
}
[ASTImporter] Import TemplateParameterLists in function templates. Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
2019-05-07 18:55:11 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportTemplateParameterLists) {
auto Code =
R"(
template<class T>
int f() { return 0; }
template <> int f<int>() { return 4; }
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(Code, Lang_CXX03);
[ASTImporter] Import TemplateParameterLists in function templates. Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
2019-05-07 18:55:11 +08:00
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(FromTU,
functionDecl(hasName("f"), isExplicitTemplateSpecialization()));
[ASTImporter] Corrected type of integer constant in a test. llvm-svn: 360156
2019-05-07 22:53:04 +08:00
ASSERT_EQ(FromD->getNumTemplateParameterLists(), 1u);
[ASTImporter] Import TemplateParameterLists in function templates. Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
2019-05-07 18:55:11 +08:00
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToD = Import(FromD, Lang_CXX03);
[ASTImporter] Import TemplateParameterLists in function templates. Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
2019-05-07 18:55:11 +08:00
// The template parameter list should exist.
[ASTImporter] Corrected type of integer constant in a test. llvm-svn: 360156
2019-05-07 22:53:04 +08:00
EXPECT_EQ(ToD->getNumTemplateParameterLists(), 1u);
[ASTImporter] Import TemplateParameterLists in function templates. Summary: Correct missing import of TemplateParameterList in function decl. Reviewers: martong, a.sidorin, shafik Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60461 llvm-svn: 360132
2019-05-07 18:55:11 +08:00
}
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
struct ASTImporterLookupTableTest : ASTImporterOptionSpecificTestBase {};
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
TEST_P(ASTImporterLookupTableTest, OneDecl) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToTU = getToTuDecl("int a;", Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *D = FirstDeclMatcher<VarDecl>().match(ToTU, varDecl(hasName("a")));
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(ToTU, D->getDeclName());
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), D);
}
static Decl *findInDeclListOfDC(DeclContext *DC, DeclarationName Name) {
for (Decl *D : DC->decls()) {
if (auto *ND = dyn_cast<NamedDecl>(D))
if (ND->getDeclName() == Name)
return ND;
}
return nullptr;
[unittests] Remove superfluous semicolon, fixing warnings with GCC. NFC. llvm-svn: 349453
2018-12-18 16:36:16 +08:00
}
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
TEST_P(ASTImporterLookupTableTest,
FriendWhichIsnotFoundByNormalLookupShouldBeFoundByImporterSpecificLookup) {
auto *Code = R"(
template <class T>
struct X {
friend void foo(){}
};
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *ToTU = getToTuDecl(Code, Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *X = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("X")));
auto *Foo = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(hasName("foo")));
DeclContext *FooDC = Foo->getDeclContext();
DeclContext *FooLexicalDC = Foo->getLexicalDeclContext();
ASSERT_EQ(cast<Decl>(FooLexicalDC), X->getTemplatedDecl());
ASSERT_EQ(cast<Decl>(FooDC), ToTU);
DeclarationName FooName = Foo->getDeclName();
// Cannot find in the LookupTable of its DC (TUDecl)
SmallVector<NamedDecl *, 2> FoundDecls;
FooDC->getRedeclContext()->localUncachedLookup(FooName, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 0u);
// Cannot find in the LookupTable of its LexicalDC (X)
FooLexicalDC->getRedeclContext()->localUncachedLookup(FooName, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 0u);
// Can't find in the list of Decls of the DC.
EXPECT_EQ(findInDeclListOfDC(FooDC, FooName), nullptr);
// Can't find in the list of Decls of the LexicalDC
EXPECT_EQ(findInDeclListOfDC(FooLexicalDC, FooName), nullptr);
// ASTImporter specific lookup finds it.
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(FooDC, Foo->getDeclName());
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), Foo);
}
TEST_P(ASTImporterLookupTableTest,
FwdDeclStructShouldBeFoundByImporterSpecificLookup) {
TranslationUnitDecl *ToTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getToTuDecl("struct A { struct Foo *p; };", Lang_C99);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *Foo =
FirstDeclMatcher<RecordDecl>().match(ToTU, recordDecl(hasName("Foo")));
auto *A =
FirstDeclMatcher<RecordDecl>().match(ToTU, recordDecl(hasName("A")));
DeclContext *FooDC = Foo->getDeclContext();
DeclContext *FooLexicalDC = Foo->getLexicalDeclContext();
ASSERT_EQ(cast<Decl>(FooLexicalDC), A);
ASSERT_EQ(cast<Decl>(FooDC), ToTU);
DeclarationName FooName = Foo->getDeclName();
// Cannot find in the LookupTable of its DC (TUDecl).
SmallVector<NamedDecl *, 2> FoundDecls;
FooDC->getRedeclContext()->localUncachedLookup(FooName, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 0u);
// Cannot find in the LookupTable of its LexicalDC (A).
FooLexicalDC->getRedeclContext()->localUncachedLookup(FooName, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 0u);
// Can't find in the list of Decls of the DC.
EXPECT_EQ(findInDeclListOfDC(FooDC, FooName), nullptr);
// Can find in the list of Decls of the LexicalDC.
EXPECT_EQ(findInDeclListOfDC(FooLexicalDC, FooName), Foo);
// ASTImporter specific lookup finds it.
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(FooDC, Foo->getDeclName());
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), Foo);
}
TEST_P(ASTImporterLookupTableTest, LookupFindsNamesInDifferentDC) {
TranslationUnitDecl *ToTU =
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
getToTuDecl("int V; struct A { int V; }; struct B { int V; };", Lang_C99);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
DeclarationName VName = FirstDeclMatcher<VarDecl>()
.match(ToTU, varDecl(hasName("V")))
->getDeclName();
auto *A =
FirstDeclMatcher<RecordDecl>().match(ToTU, recordDecl(hasName("A")));
auto *B =
FirstDeclMatcher<RecordDecl>().match(ToTU, recordDecl(hasName("B")));
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(cast<DeclContext>(A), VName);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), FirstDeclMatcher<FieldDecl>().match(
ToTU, fieldDecl(hasName("V"),
hasParent(recordDecl(hasName("A"))))));
Res = LT.lookup(cast<DeclContext>(B), VName);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), FirstDeclMatcher<FieldDecl>().match(
ToTU, fieldDecl(hasName("V"),
hasParent(recordDecl(hasName("B"))))));
Res = LT.lookup(ToTU, VName);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), FirstDeclMatcher<VarDecl>().match(
ToTU, varDecl(hasName("V"),
hasParent(translationUnitDecl()))));
}
TEST_P(ASTImporterLookupTableTest, LookupFindsOverloadedNames) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
void foo();
void foo(int);
void foo(int, int);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F0 = FirstDeclMatcher<FunctionDecl>().match(ToTU, functionDecl());
auto *F2 = LastDeclMatcher<FunctionDecl>().match(ToTU, functionDecl());
DeclarationName Name = F0->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 3u);
EXPECT_EQ(Res.count(F0), 1u);
EXPECT_EQ(Res.count(F2), 1u);
}
[ASTImporter][ASTImporterSpecificLookup] Add test for different operators 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
2019-02-08 17:19:34 +08:00
TEST_P(ASTImporterLookupTableTest,
DifferentOperatorsShouldHaveDifferentResultSet) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
struct X{};
void operator+(X, X);
void operator-(X, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter][ASTImporterSpecificLookup] Add test for different operators 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
2019-02-08 17:19:34 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *FPlus = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(hasOverloadedOperatorName("+")));
auto *FMinus = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(hasOverloadedOperatorName("-")));
DeclarationName NamePlus = FPlus->getDeclName();
auto ResPlus = LT.lookup(ToTU, NamePlus);
EXPECT_EQ(ResPlus.size(), 1u);
EXPECT_EQ(ResPlus.count(FPlus), 1u);
EXPECT_EQ(ResPlus.count(FMinus), 0u);
DeclarationName NameMinus = FMinus->getDeclName();
auto ResMinus = LT.lookup(ToTU, NameMinus);
EXPECT_EQ(ResMinus.size(), 1u);
EXPECT_EQ(ResMinus.count(FMinus), 1u);
EXPECT_EQ(ResMinus.count(FPlus), 0u);
EXPECT_NE(*ResMinus.begin(), *ResPlus.begin());
}
TEST_P(ASTImporterLookupTableTest, LookupDeclNamesFromDifferentTUs) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
struct X {};
void operator+(X, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter][ASTImporterSpecificLookup] Add test for different operators 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
2019-02-08 17:19:34 +08:00
auto *ToPlus = FirstDeclMatcher<FunctionDecl>().match(
ToTU, functionDecl(hasOverloadedOperatorName("+")));
Decl *FromTU = getTuDecl(
R"(
struct X {};
void operator+(X, X);
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter][ASTImporterSpecificLookup] Add test for different operators 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
2019-02-08 17:19:34 +08:00
auto *FromPlus = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasOverloadedOperatorName("+")));
// FromPlus have a different TU, thus its DeclarationName is different too.
ASSERT_NE(ToPlus->getDeclName(), FromPlus->getDeclName());
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(ToTU, ToPlus->getDeclName());
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), ToPlus);
// FromPlus have a different TU, thus its DeclarationName is different too.
Res = LT.lookup(ToTU, FromPlus->getDeclName());
ASSERT_EQ(Res.size(), 0u);
}
[ASTImporter] Fix unhandled cases in ASTImporterLookupTable 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
2019-06-11 21:35:25 +08:00
TEST_P(ASTImporterLookupTableTest,
LookupFindsFwdFriendClassDeclWithElaboratedType) {
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class Y { friend class F; };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
// In this case, the CXXRecordDecl is hidden, the FriendDecl is not a parent.
// So we must dig up the underlying CXXRecordDecl.
ASTImporterLookupTable LT(*ToTU);
auto *FriendD = FirstDeclMatcher<FriendDecl>().match(ToTU, friendDecl());
const RecordDecl *RD = getRecordDeclOfFriend(FriendD);
auto *Y = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("Y")));
DeclarationName Name = RD->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), RD);
Res = LT.lookup(Y, Name);
EXPECT_EQ(Res.size(), 0u);
}
[ASTImporter] Fix unhandled cases in ASTImporterLookupTable 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
2019-06-11 21:35:25 +08:00
TEST_P(ASTImporterLookupTableTest,
LookupFindsFwdFriendClassDeclWithUnelaboratedType) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class F;
class Y { friend F; };
)",
Lang_CXX11);
// In this case, the CXXRecordDecl is hidden, the FriendDecl is not a parent.
// So we must dig up the underlying CXXRecordDecl.
ASTImporterLookupTable LT(*ToTU);
auto *FriendD = FirstDeclMatcher<FriendDecl>().match(ToTU, friendDecl());
const RecordDecl *RD = getRecordDeclOfFriend(FriendD);
auto *Y = FirstDeclMatcher<CXXRecordDecl>().match(ToTU, cxxRecordDecl(hasName("Y")));
DeclarationName Name = RD->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), RD);
Res = LT.lookup(Y, Name);
EXPECT_EQ(Res.size(), 0u);
}
TEST_P(ASTImporterLookupTableTest,
LookupFindsFriendClassDeclWithTypeAliasDoesNotAssert) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class F;
using alias_of_f = F;
class Y { friend alias_of_f; };
)",
Lang_CXX11);
// ASTImporterLookupTable constructor handles using declarations correctly,
// no assert is expected.
ASTImporterLookupTable LT(*ToTU);
auto *Alias = FirstDeclMatcher<TypeAliasDecl>().match(
ToTU, typeAliasDecl(hasName("alias_of_f")));
DeclarationName Name = Alias->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.count(Alias), 1u);
}
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
TEST_P(ASTImporterLookupTableTest, LookupFindsFwdFriendClassTemplateDecl) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class Y { template <class T> friend class F; };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("F")));
DeclarationName Name = F->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 2u);
EXPECT_EQ(Res.count(F), 1u);
EXPECT_EQ(Res.count(F->getTemplatedDecl()), 1u);
}
TEST_P(ASTImporterLookupTableTest, DependentFriendClass) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
template <typename T>
class F;
template <typename T>
class Y {
friend class F<T>;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("F")));
DeclarationName Name = F->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 2u);
EXPECT_EQ(Res.count(F), 1u);
EXPECT_EQ(Res.count(F->getTemplatedDecl()), 1u);
}
TEST_P(ASTImporterLookupTableTest, FriendClassTemplateSpecialization) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
template <typename T>
class F;
class Y {
friend class F<int>;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("F")));
DeclarationName Name = F->getDeclName();
auto Res = LT.lookup(ToTU, Name);
ASSERT_EQ(Res.size(), 3u);
EXPECT_EQ(Res.count(F), 1u);
EXPECT_EQ(Res.count(F->getTemplatedDecl()), 1u);
EXPECT_EQ(Res.count(*F->spec_begin()), 1u);
}
TEST_P(ASTImporterLookupTableTest, LookupFindsFwdFriendFunctionDecl) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class Y { friend void F(); };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F =
FirstDeclMatcher<FunctionDecl>().match(ToTU, functionDecl(hasName("F")));
DeclarationName Name = F->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), F);
}
TEST_P(ASTImporterLookupTableTest,
LookupFindsDeclsInClassTemplateSpecialization) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
template <typename T>
struct X {
int F;
};
void foo() {
X<char> xc;
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *Template = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("X")));
auto *FieldInTemplate = FirstDeclMatcher<FieldDecl>().match(
ToTU,
fieldDecl(hasParent(cxxRecordDecl(hasParent(classTemplateDecl())))));
auto *Spec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X")));
FieldDecl *FieldInSpec = *Spec->field_begin();
ASSERT_TRUE(FieldInSpec);
DeclarationName Name = FieldInSpec->getDeclName();
auto TemplateDC = cast<DeclContext>(Template->getTemplatedDecl());
SmallVector<NamedDecl *, 2> FoundDecls;
TemplateDC->getRedeclContext()->localUncachedLookup(Name, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 1u);
EXPECT_EQ(FoundDecls[0], FieldInTemplate);
auto Res = LT.lookup(TemplateDC, Name);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), FieldInTemplate);
cast<DeclContext>(Spec)->getRedeclContext()->localUncachedLookup(Name,
FoundDecls);
EXPECT_EQ(FoundDecls.size(), 1u);
EXPECT_EQ(FoundDecls[0], FieldInSpec);
Res = LT.lookup(cast<DeclContext>(Spec), Name);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), FieldInSpec);
}
TEST_P(ASTImporterLookupTableTest, LookupFindsFwdFriendFunctionTemplateDecl) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
class Y { template <class T> friend void F(); };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *F = FirstDeclMatcher<FunctionTemplateDecl>().match(
ToTU, functionTemplateDecl(hasName("F")));
DeclarationName Name = F->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 2u);
EXPECT_EQ(Res.count(F), 1u);
EXPECT_EQ(Res.count(F->getTemplatedDecl()), 1u);
}
TEST_P(ASTImporterLookupTableTest, MultipleBefriendingClasses) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
struct X;
struct A {
friend struct X;
};
struct B {
friend struct X;
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *X = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("X")));
auto *FriendD0 = FirstDeclMatcher<FriendDecl>().match(ToTU, friendDecl());
auto *FriendD1 = LastDeclMatcher<FriendDecl>().match(ToTU, friendDecl());
const RecordDecl *RD0 = getRecordDeclOfFriend(FriendD0);
const RecordDecl *RD1 = getRecordDeclOfFriend(FriendD1);
ASSERT_EQ(RD0, RD1);
ASSERT_EQ(RD1, X);
DeclarationName Name = X->getDeclName();
auto Res = LT.lookup(ToTU, Name);
EXPECT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), X);
}
TEST_P(ASTImporterLookupTableTest, EnumConstantDecl) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
enum E {
A,
B
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_C99);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
ASTImporterLookupTable LT(*ToTU);
auto *E = FirstDeclMatcher<EnumDecl>().match(ToTU, enumDecl(hasName("E")));
auto *A = FirstDeclMatcher<EnumConstantDecl>().match(
ToTU, enumConstantDecl(hasName("A")));
DeclarationName Name = A->getDeclName();
// Redecl context is the TU.
ASSERT_EQ(E->getRedeclContext(), ToTU);
SmallVector<NamedDecl *, 2> FoundDecls;
// Normal lookup finds in the DC.
E->localUncachedLookup(Name, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 1u);
// Normal lookup finds in the Redecl context.
ToTU->localUncachedLookup(Name, FoundDecls);
EXPECT_EQ(FoundDecls.size(), 1u);
// Import specific lookup finds in the DC.
auto Res = LT.lookup(E, Name);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), A);
// Import specific lookup finds in the Redecl context.
Res = LT.lookup(ToTU, Name);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), A);
}
TEST_P(ASTImporterLookupTableTest, LookupSearchesInTheWholeRedeclChain) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
namespace N {
int A;
}
namespace N {
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
auto *N1 =
LastDeclMatcher<NamespaceDecl>().match(ToTU, namespaceDecl(hasName("N")));
auto *A = FirstDeclMatcher<VarDecl>().match(ToTU, varDecl(hasName("A")));
DeclarationName Name = A->getDeclName();
ASTImporterLookupTable LT(*ToTU);
auto Res = LT.lookup(N1, Name);
ASSERT_EQ(Res.size(), 1u);
EXPECT_EQ(*Res.begin(), A);
}
[ASTImporter] Add test RedeclChainShouldBeCorrectAmongstNamespaces 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
2019-02-11 18:27:58 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
[ASTImporter][NFC] Enable disabled but passing test RedeclChainShouldBeCorrectAmongstNamespaces llvm-svn: 373896
2019-10-07 19:34:54 +08:00
RedeclChainShouldBeCorrectAmongstNamespaces) {
[ASTImporter] Add test RedeclChainShouldBeCorrectAmongstNamespaces 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
2019-02-11 18:27:58 +08:00
Decl *FromTU = getTuDecl(
R"(
namespace NS {
struct X;
struct Y {
static const int I = 3;
};
}
namespace NS {
struct X { // <--- To be imported
void method(int i = Y::I) {}
int f;
};
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Add test RedeclChainShouldBeCorrectAmongstNamespaces 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
2019-02-11 18:27:58 +08:00
auto *FromFwd = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X"), unless(isImplicit())));
auto *FromDef = LastDeclMatcher<CXXRecordDecl>().match(
FromTU,
cxxRecordDecl(hasName("X"), isDefinition(), unless(isImplicit())));
ASSERT_NE(FromFwd, FromDef);
ASSERT_FALSE(FromFwd->isThisDeclarationADefinition());
ASSERT_TRUE(FromDef->isThisDeclarationADefinition());
ASSERT_EQ(FromFwd->getCanonicalDecl(), FromDef->getCanonicalDecl());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ToDef = cast_or_null<CXXRecordDecl>(Import(FromDef, Lang_CXX03));
auto *ToFwd = cast_or_null<CXXRecordDecl>(Import(FromFwd, Lang_CXX03));
[ASTImporter] Add test RedeclChainShouldBeCorrectAmongstNamespaces 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
2019-02-11 18:27:58 +08:00
EXPECT_NE(ToFwd, ToDef);
EXPECT_FALSE(ToFwd->isThisDeclarationADefinition());
EXPECT_TRUE(ToDef->isThisDeclarationADefinition());
EXPECT_EQ(ToFwd->getCanonicalDecl(), ToDef->getCanonicalDecl());
auto *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// We expect no (ODR) warning during the import.
EXPECT_EQ(0u, ToTU->getASTContext().getDiagnostics().getNumWarnings());
}
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
struct ImportFriendFunctionTemplates : ASTImporterOptionSpecificTestBase {};
TEST_P(ImportFriendFunctionTemplates, LookupShouldFindPreviousFriend) {
Decl *ToTU = getToTuDecl(
R"(
class X {
template <typename T> friend void foo();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
auto *Friend = FirstDeclMatcher<FunctionTemplateDecl>().match(
ToTU, functionTemplateDecl(hasName("foo")));
Decl *FromTU = getTuDecl(
R"(
template <typename T> void foo();
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
auto *FromFoo = FirstDeclMatcher<FunctionTemplateDecl>().match(
FromTU, functionTemplateDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *Imported = Import(FromFoo, Lang_CXX03);
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
[ASTImporter] Handle redecl chain of FunctionTemplateDecls 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
2019-03-07 21:01:51 +08:00
EXPECT_EQ(Imported->getPreviousDecl(), Friend);
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
}
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
struct ASTImporterWithFakeErrors : ASTImporter {
using ASTImporter::ASTImporter;
bool returnWithErrorInTest() override { return true; }
};
struct ErrorHandlingTest : ASTImporterOptionSpecificTestBase {
ErrorHandlingTest() {
Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
ASTContext &FromContext, FileManager &FromFileManager,
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
bool MinimalImport,
const std::shared_ptr<ASTImporterSharedState> &SharedState) {
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
return new ASTImporterWithFakeErrors(ToContext, ToFileManager,
FromContext, FromFileManager,
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
MinimalImport, SharedState);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
};
}
// In this test we purposely report an error (UnsupportedConstruct) when
// importing the below stmt.
static constexpr auto* ErroneousStmt = R"( asm(""); )";
};
// Check a case when no new AST node is created in the AST before encountering
// the error.
TEST_P(ErrorHandlingTest, ErrorHappensBeforeCreatingANewNode) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
template <typename T>
class X {};
template <>
class X<int> { int a; };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
TranslationUnitDecl *FromTU = getTuDecl(
R"(
template <typename T>
class X {};
template <>
class X<int> { double b; };
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
auto *FromSpec = FirstDeclMatcher<ClassTemplateSpecializationDecl>().match(
FromTU, classTemplateSpecializationDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ClassTemplateSpecializationDecl *ImportedSpec = Import(FromSpec, Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
EXPECT_FALSE(ImportedSpec);
// The original Decl is kept, no new decl is created.
EXPECT_EQ(DeclCounter<ClassTemplateSpecializationDecl>().match(
ToTU, classTemplateSpecializationDecl(hasName("X"))),
1u);
// But an error is set to the counterpart in the "from" context.
ASTImporter *Importer = findFromTU(FromSpec)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromSpec);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::NameConflict);
}
// Check a case when a new AST node is created but not linked to the AST before
// encountering the error.
TEST_P(ErrorHandlingTest,
ErrorHappensAfterCreatingTheNodeButBeforeLinkingThatToTheAST) {
TranslationUnitDecl *FromTU = getTuDecl(
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
std::string("void foo() { ") + ErroneousStmt + " }", Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
auto *FromFoo = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ImportedFoo = Import(FromFoo, Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
EXPECT_FALSE(ImportedFoo);
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// Created, but not linked.
EXPECT_EQ(
DeclCounter<FunctionDecl>().match(ToTU, functionDecl(hasName("foo"))),
0u);
ASTImporter *Importer = findFromTU(FromFoo)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromFoo);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
}
// Check a case when a new AST node is created and linked to the AST before
// encountering the error. The error is set for the counterpart of the nodes in
// the "from" context.
TEST_P(ErrorHandlingTest, ErrorHappensAfterNodeIsCreatedAndLinked) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
void f();
void f() { )") + ErroneousStmt + R"( }
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
auto *FromProto = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
auto *FromDef =
LastDeclMatcher<FunctionDecl>().match(FromTU, functionDecl(hasName("f")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ImportedProto = Import(FromProto, Lang_CXX03);
[ASTImporter] Store import errors for Decls 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
2019-06-25 16:00:51 +08:00
EXPECT_FALSE(ImportedProto); // Could not import.
// However, we created two nodes in the AST. 1) the fwd decl 2) the
// definition. The definition is not added to its DC, but the fwd decl is
// there.
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
EXPECT_EQ(DeclCounter<FunctionDecl>().match(ToTU, functionDecl(hasName("f"))),
1u);
// Match the fwd decl.
auto *ToProto =
FirstDeclMatcher<FunctionDecl>().match(ToTU, functionDecl(hasName("f")));
EXPECT_TRUE(ToProto);
// An error is set to the counterpart in the "from" context both for the fwd
// decl and the definition.
ASTImporter *Importer = findFromTU(FromProto)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromProto);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
OptErr = Importer->getImportDeclErrorIfAny(FromDef);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
}
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
// An error should be set for a class if we cannot import one member.
TEST_P(ErrorHandlingTest, ErrorIsPropagatedFromMemberToClass) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
class X {
void f() { )") + ErroneousStmt + R"( } // This member has the error
// during import.
void ok(); // The error should not prevent importing this.
}; // An error will be set for X too.
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXRecordDecl *ImportedX = Import(FromX, Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
// An error is set for X.
EXPECT_FALSE(ImportedX);
ASTImporter *Importer = findFromTU(FromX)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromX);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
// An error is set for f().
auto *FromF = FirstDeclMatcher<CXXMethodDecl>().match(
FromTU, cxxMethodDecl(hasName("f")));
OptErr = Importer->getImportDeclErrorIfAny(FromF);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
// And any subsequent import should fail.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXMethodDecl *ImportedF = Import(FromF, Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
EXPECT_FALSE(ImportedF);
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// There is an error set for the other member too.
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
auto *FromOK = FirstDeclMatcher<CXXMethodDecl>().match(
FromTU, cxxMethodDecl(hasName("ok")));
OptErr = Importer->getImportDeclErrorIfAny(FromOK);
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
EXPECT_TRUE(OptErr);
// Cannot import the other member.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXMethodDecl *ImportedOK = Import(FromOK, Lang_CXX03);
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
EXPECT_FALSE(ImportedOK);
}
// Check that an error propagates to the dependent AST nodes.
// In the below code it means that an error in X should propagate to A.
// And even to F since the containing A is erroneous.
// And to all AST nodes which we visit during the import process which finally
// ends up in a failure (in the error() function).
TEST_P(ErrorHandlingTest, ErrorPropagatesThroughImportCycles) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl(std::string(R"(
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
namespace NS {
class A {
template <int I> class F {};
class X {
template <int I> friend class F;
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
void error() { )") +
ErroneousStmt + R"( }
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
};
};
class B {};
} // NS
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input0.cc");
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
auto *FromFRD = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("F"), isDefinition()));
auto *FromA = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A"), isDefinition()));
auto *FromB = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("B"), isDefinition()));
auto *FromNS = FirstDeclMatcher<NamespaceDecl>().match(
FromTU, namespaceDecl(hasName("NS")));
// Start by importing the templated CXXRecordDecl of F.
// Import fails for that.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
EXPECT_FALSE(Import(FromFRD, Lang_CXX03));
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// Import fails for A.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
EXPECT_FALSE(Import(FromA, Lang_CXX03));
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// But we should be able to import the independent B.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
EXPECT_TRUE(Import(FromB, Lang_CXX03));
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// And the namespace.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
EXPECT_TRUE(Import(FromNS, Lang_CXX03));
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// An error is set to the templated CXXRecordDecl of F.
ASTImporter *Importer = findFromTU(FromFRD)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromFRD);
EXPECT_TRUE(OptErr);
// An error is set to A.
OptErr = Importer->getImportDeclErrorIfAny(FromA);
EXPECT_TRUE(OptErr);
// There is no error set to B.
OptErr = Importer->getImportDeclErrorIfAny(FromB);
EXPECT_FALSE(OptErr);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
// There is no error set to NS.
OptErr = Importer->getImportDeclErrorIfAny(FromNS);
EXPECT_FALSE(OptErr);
// Check some of those decls whose ancestor is X, they all should have an
// error set if we visited them during an import process which finally failed.
// These decls are part of a cycle in an ImportPath.
// There would not be any error set for these decls if we hadn't follow the
// ImportPaths and the cycles.
OptErr = Importer->getImportDeclErrorIfAny(
FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("F"))));
// An error is set to the 'F' ClassTemplateDecl.
EXPECT_TRUE(OptErr);
// An error is set to the FriendDecl.
OptErr = Importer->getImportDeclErrorIfAny(
FirstDeclMatcher<FriendDecl>().match(
FromTU, friendDecl()));
EXPECT_TRUE(OptErr);
// An error is set to the implicit class of A.
OptErr =
Importer->getImportDeclErrorIfAny(FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("A"), isImplicit())));
EXPECT_TRUE(OptErr);
// An error is set to the implicit class of X.
OptErr =
Importer->getImportDeclErrorIfAny(FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X"), isImplicit())));
EXPECT_TRUE(OptErr);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
}
TEST_P(ErrorHandlingTest, ErrorIsNotPropagatedFromMemberToNamespace) {
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
namespace X {
void f() { )") + ErroneousStmt + R"( } // This member has the error
// during import.
void ok(); // The error should not prevent importing this.
}; // An error will be set for X too.
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
auto *FromX = FirstDeclMatcher<NamespaceDecl>().match(
FromTU, namespaceDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
NamespaceDecl *ImportedX = Import(FromX, Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
// There is no error set for X.
EXPECT_TRUE(ImportedX);
ASTImporter *Importer = findFromTU(FromX)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromX);
ASSERT_FALSE(OptErr);
// An error is set for f().
auto *FromF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
OptErr = Importer->getImportDeclErrorIfAny(FromF);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
// And any subsequent import should fail.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ImportedF = Import(FromF, Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
EXPECT_FALSE(ImportedF);
// There is no error set for ok().
auto *FromOK = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("ok")));
OptErr = Importer->getImportDeclErrorIfAny(FromOK);
EXPECT_FALSE(OptErr);
// And we should be able to import.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ImportedOK = Import(FromOK, Lang_CXX03);
[ASTImporter] Propagate error from ImportDeclContext 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
2019-07-01 20:44:39 +08:00
EXPECT_TRUE(ImportedOK);
}
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
// An error should be set for a class if it had a previous import with an error
// from another TU.
TEST_P(ErrorHandlingTest,
ImportedDeclWithErrorShouldFailTheImportOfDeclWhichMapToIt) {
// We already have a fwd decl.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *ToTU = getToTuDecl("class X;", Lang_CXX03);
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
// Then we import a definition.
{
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
class X {
void f() { )") + ErroneousStmt + R"( }
void ok();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXRecordDecl *ImportedX = Import(FromX, Lang_CXX03);
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
// An error is set for X ...
EXPECT_FALSE(ImportedX);
ASTImporter *Importer = findFromTU(FromX)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromX);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
}
// ... but the node had been created.
auto *ToXDef = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("X"), isDefinition()));
// An error is set for "ToXDef" in the shared state.
Optional<ImportError> OptErr =
SharedStatePtr->getImportDeclErrorIfAny(ToXDef);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
auto *ToXFwd = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("X"), unless(isDefinition())));
// An error is NOT set for the fwd Decl of X in the shared state.
OptErr = SharedStatePtr->getImportDeclErrorIfAny(ToXFwd);
ASSERT_FALSE(OptErr);
// Try to import X again but from another TU.
{
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
class X {
void f() { )") + ErroneousStmt + R"( }
void ok();
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03, "input1.cc");
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
CXXRecordDecl *ImportedX = Import(FromX, Lang_CXX03);
[ASTImporter] Mark erroneous nodes in shared st 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
2019-07-01 23:37:07 +08:00
// If we did not save the errors for the "to" context then the below checks
// would fail, because the lookup finds the fwd Decl of the existing
// definition in the "to" context. We can reach the existing definition via
// the found fwd Decl. That existing definition is structurally equivalent
// (we check only the fields) with this one we want to import, so we return
// with the existing definition, which is erroneous (one method is missing).
// The import should fail.
EXPECT_FALSE(ImportedX);
ASTImporter *Importer = findFromTU(FromX)->Importer.get();
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromX);
// And an error is set for this new X in the "from" ctx.
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
}
}
[ASTImporter] Propagate errors during import of overridden methods. 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
2019-08-30 18:12:14 +08:00
TEST_P(ErrorHandlingTest, ImportOfOverriddenMethods) {
auto MatchFooA =
functionDecl(hasName("foo"), hasAncestor(cxxRecordDecl(hasName("A"))));
auto MatchFooB =
functionDecl(hasName("foo"), hasAncestor(cxxRecordDecl(hasName("B"))));
auto MatchFooC =
functionDecl(hasName("foo"), hasAncestor(cxxRecordDecl(hasName("C"))));
// Provoke import of a method that has overridden methods with import error.
TranslationUnitDecl *FromTU = getTuDecl(std::string(R"(
struct C;
struct A {
virtual void foo();
void f1(C *);
};
void A::foo() {
)") + ErroneousStmt + R"(
}
struct B : public A {
void foo() override;
};
struct C : public B {
void foo() override;
};
)",
Lang_CXX11);
auto *FromFooA = FirstDeclMatcher<FunctionDecl>().match(FromTU, MatchFooA);
auto *FromFooB = FirstDeclMatcher<FunctionDecl>().match(FromTU, MatchFooB);
auto *FromFooC = FirstDeclMatcher<FunctionDecl>().match(FromTU, MatchFooC);
EXPECT_FALSE(Import(FromFooA, Lang_CXX11));
ASTImporter *Importer = findFromTU(FromFooA)->Importer.get();
auto CheckError = [&Importer](Decl *FromD) {
Optional<ImportError> OptErr = Importer->getImportDeclErrorIfAny(FromD);
ASSERT_TRUE(OptErr);
EXPECT_EQ(OptErr->Error, ImportError::UnsupportedConstruct);
};
CheckError(FromFooA);
EXPECT_FALSE(Import(FromFooB, Lang_CXX11));
CheckError(FromFooB);
EXPECT_FALSE(Import(FromFooC, Lang_CXX11));
CheckError(FromFooC);
}
[ASTImporter] Fix import of lambda in function param 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
2019-07-08 20:49:13 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, LambdaInFunctionBody) {
Decl *FromTU = getTuDecl(
R"(
void f() {
auto L = [](){};
}
)",
Lang_CXX11, "input0.cc");
auto Pattern = lambdaExpr();
CXXRecordDecl *FromL =
FirstDeclMatcher<LambdaExpr>().match(FromTU, Pattern)->getLambdaClass();
auto ToL = Import(FromL, Lang_CXX11);
unsigned ToLSize = std::distance(ToL->decls().begin(), ToL->decls().end());
unsigned FromLSize =
std::distance(FromL->decls().begin(), FromL->decls().end());
EXPECT_NE(ToLSize, 0u);
EXPECT_EQ(ToLSize, FromLSize);
}
TEST_P(ASTImporterOptionSpecificTestBase, LambdaInFunctionParam) {
Decl *FromTU = getTuDecl(
R"(
template <typename F>
void f(F L = [](){}) {}
)",
Lang_CXX11, "input0.cc");
auto Pattern = lambdaExpr();
CXXRecordDecl *FromL =
FirstDeclMatcher<LambdaExpr>().match(FromTU, Pattern)->getLambdaClass();
auto ToL = Import(FromL, Lang_CXX11);
unsigned ToLSize = std::distance(ToL->decls().begin(), ToL->decls().end());
unsigned FromLSize =
std::distance(FromL->decls().begin(), FromL->decls().end());
EXPECT_NE(ToLSize, 0u);
EXPECT_EQ(ToLSize, FromLSize);
}
[ASTImporter] Fix structural eq of lambdas 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
2019-07-17 22:40:09 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, LambdaInGlobalScope) {
Decl *FromTU = getTuDecl(
R"(
auto l1 = [](unsigned lp) { return 1; };
auto l2 = [](int lp) { return 2; };
int f(int p) {
return l1(p) + l2(p);
}
)",
Lang_CXX11, "input0.cc");
FunctionDecl *FromF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
FunctionDecl *ToF = Import(FromF, Lang_CXX11);
EXPECT_TRUE(ToF);
}
[ASTImporter] Fix for import of friend class template with definition. 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
2019-08-12 18:07:38 +08:00
TEST_P(ASTImporterOptionSpecificTestBase,
ImportExistingFriendClassTemplateDef) {
auto Code =
R"(
template <class T1, class T2>
struct Base {
template <class U1, class U2>
friend struct Class;
};
template <class T1, class T2>
struct Class { };
)";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *ToTU = getToTuDecl(Code, Lang_CXX03);
TranslationUnitDecl *FromTU = getTuDecl(Code, Lang_CXX03, "input.cc");
[ASTImporter] Fix for import of friend class template with definition. 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
2019-08-12 18:07:38 +08:00
auto *ToClassProto = FirstDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("Class")));
auto *ToClassDef = LastDeclMatcher<ClassTemplateDecl>().match(
ToTU, classTemplateDecl(hasName("Class")));
ASSERT_FALSE(ToClassProto->isThisDeclarationADefinition());
ASSERT_TRUE(ToClassDef->isThisDeclarationADefinition());
// Previous friend decl is not linked to it!
ASSERT_FALSE(ToClassDef->getPreviousDecl());
ASSERT_EQ(ToClassDef->getMostRecentDecl(), ToClassDef);
ASSERT_EQ(ToClassProto->getMostRecentDecl(), ToClassProto);
auto *FromClassProto = FirstDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("Class")));
auto *FromClassDef = LastDeclMatcher<ClassTemplateDecl>().match(
FromTU, classTemplateDecl(hasName("Class")));
ASSERT_FALSE(FromClassProto->isThisDeclarationADefinition());
ASSERT_TRUE(FromClassDef->isThisDeclarationADefinition());
ASSERT_FALSE(FromClassDef->getPreviousDecl());
ASSERT_EQ(FromClassDef->getMostRecentDecl(), FromClassDef);
ASSERT_EQ(FromClassProto->getMostRecentDecl(), FromClassProto);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedDef = Import(FromClassDef, Lang_CXX03);
[ASTImporter] Fix for import of friend class template with definition. 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
2019-08-12 18:07:38 +08:00
// At import we should find the definition for 'Class' even if the
// prototype (inside 'friend') for it comes first in the AST and is not
// linked to the definition.
EXPECT_EQ(ImportedDef, ToClassDef);
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
}
[ASTImporter] Fix LLDB lookup in transparent ctx and with ext src 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
2019-07-17 21:47:46 +08:00
struct LLDBLookupTest : ASTImporterOptionSpecificTestBase {
LLDBLookupTest() {
Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
ASTContext &FromContext, FileManager &FromFileManager,
bool MinimalImport,
const std::shared_ptr<ASTImporterSharedState> &SharedState) {
return new ASTImporter(ToContext, ToFileManager, FromContext,
FromFileManager, MinimalImport,
// We use the regular lookup.
/*SharedState=*/nullptr);
};
}
};
TEST_P(LLDBLookupTest, ImporterShouldFindInTransparentContext) {
TranslationUnitDecl *ToTU = getToTuDecl(
R"(
extern "C" {
class X{};
};
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Fix LLDB lookup in transparent ctx and with ext src 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
2019-07-17 21:47:46 +08:00
auto *ToX = FirstDeclMatcher<CXXRecordDecl>().match(
ToTU, cxxRecordDecl(hasName("X")));
// Set up a stub external storage.
ToTU->setHasExternalLexicalStorage(true);
// Set up DeclContextBits.HasLazyExternalLexicalLookups to true.
ToTU->setMustBuildLookupTable();
struct TestExternalASTSource : ExternalASTSource {};
ToTU->getASTContext().setExternalSource(new TestExternalASTSource());
Decl *FromTU = getTuDecl(
R"(
class X;
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX03);
[ASTImporter] Fix LLDB lookup in transparent ctx and with ext src 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
2019-07-17 21:47:46 +08:00
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
auto *ImportedX = Import(FromX, Lang_CXX03);
[ASTImporter] Fix LLDB lookup in transparent ctx and with ext src 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
2019-07-17 21:47:46 +08:00
// The lookup must find the existing class definition in the LinkageSpecDecl.
// Then the importer renders the existing and the new decl into one chain.
EXPECT_EQ(ImportedX->getCanonicalDecl(), ToX->getCanonicalDecl());
}
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
struct SVEBuiltins : ASTImporterOptionSpecificTestBase {};
TEST_P(SVEBuiltins, ImportTypes) {
static const char *const TypeNames[] = {
"__SVInt8_t",
"__SVInt16_t",
"__SVInt32_t",
"__SVInt64_t",
"__SVUint8_t",
"__SVUint16_t",
"__SVUint32_t",
"__SVUint64_t",
"__SVFloat16_t",
[llvm][SveEmitter] Emit the bfloat version of `svld1ro`. Summary: The new SVE builtin type __SVBFloat16_t` is used to represent scalable vectors of bfloat elements. Reviewers: sdesmalen, efriedma, stuij, ctetreau, shafik, rengolin Subscribers: tschuett, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81304
2020-06-16 04:48:13 +08:00
"__SVBFloat16_t",
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
"__SVFloat32_t",
"__SVFloat64_t",
"__SVBool_t"
};
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *ToTU = getToTuDecl("", Lang_CXX03);
TranslationUnitDecl *FromTU = getTuDecl("", Lang_CXX03, "input.cc");
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
for (auto *TypeName : TypeNames) {
auto *ToTypedef = FirstDeclMatcher<TypedefDecl>().match(
ToTU, typedefDecl(hasName(TypeName)));
QualType ToType = ToTypedef->getUnderlyingType();
auto *FromTypedef = FirstDeclMatcher<TypedefDecl>().match(
FromTU, typedefDecl(hasName(TypeName)));
QualType FromType = FromTypedef->getUnderlyingType();
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
QualType ImportedType = ImportType(FromType, FromTypedef, Lang_CXX03);
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
EXPECT_EQ(ImportedType, ToType);
}
}
[ASTImporter] Import additional flags for functions. Summary: At AST import of function delcarations import the flags for defaulted and deleted. 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/D65999 llvm-svn: 368655
2019-08-13 16:04:06 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportOfDefaultImplicitFunctions) {
// Test that import of implicit functions works and the functions
// are merged into one chain.
auto GetDeclToImport = [this](StringRef File) {
Decl *FromTU = getTuDecl(
R"(
struct X { };
// Force generating some implicit operator definitions for X.
void f() { X x1, x2; x1 = x2; X *x3 = new X; delete x3; }
)",
Lang_CXX11, File);
auto *FromD = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X"), unless(isImplicit())));
// Destructor is picked as one example of implicit function.
return FromD->getDestructor();
};
auto *ToD1 = Import(GetDeclToImport("input1.cc"), Lang_CXX11);
ASSERT_TRUE(ToD1);
auto *ToD2 = Import(GetDeclToImport("input2.cc"), Lang_CXX11);
ASSERT_TRUE(ToD2);
EXPECT_EQ(ToD1->getCanonicalDecl(), ToD2->getCanonicalDecl());
}
TEST_P(ASTImporterOptionSpecificTestBase,
ImportOfExplicitlyDefaultedOrDeleted) {
Decl *FromTU = getTuDecl(
R"(
struct X { X() = default; X(const X&) = delete; };
)",
Lang_CXX11);
auto *FromX = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("X")));
auto *ImportedX = Import(FromX, Lang_CXX11);
auto *Constr1 = FirstDeclMatcher<CXXConstructorDecl>().match(
ImportedX, cxxConstructorDecl(hasName("X"), unless(isImplicit())));
auto *Constr2 = LastDeclMatcher<CXXConstructorDecl>().match(
ImportedX, cxxConstructorDecl(hasName("X"), unless(isImplicit())));
ASSERT_TRUE(ImportedX);
EXPECT_TRUE(Constr1->isDefaulted());
EXPECT_TRUE(Constr1->isExplicitlyDefaulted());
EXPECT_TRUE(Constr2->isDeletedAsWritten());
EXPECT_EQ(ImportedX->isAggregate(), FromX->isAggregate());
}
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, SVEBuiltins,
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
::testing::Values(std::vector<std::string>{
"-target", "aarch64-linux-gnu"}), );
Add SVE opaque built-in types 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
2019-08-09 16:52:54 +08:00
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, DeclContextTest,
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
::testing::Values(std::vector<std::string>()), );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, CanonicalRedeclChain,
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
::testing::Values(std::vector<std::string>()), );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
[ASTImporter] Do not look up lambda classes 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
2019-08-30 18:55:41 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, LambdasAreDifferentiated) {
Decl *FromTU = getTuDecl(
R"(
void f() {
auto L0 = [](){};
auto L1 = [](){};
}
)",
Lang_CXX11, "input0.cc");
auto Pattern = lambdaExpr();
CXXRecordDecl *FromL0 =
FirstDeclMatcher<LambdaExpr>().match(FromTU, Pattern)->getLambdaClass();
CXXRecordDecl *FromL1 =
LastDeclMatcher<LambdaExpr>().match(FromTU, Pattern)->getLambdaClass();
ASSERT_NE(FromL0, FromL1);
CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
EXPECT_NE(ToL0, ToL1);
}
TEST_P(ASTImporterOptionSpecificTestBase,
LambdasInFunctionParamsAreDifferentiated) {
Decl *FromTU = getTuDecl(
R"(
template <typename F0, typename F1>
void f(F0 L0 = [](){}, F1 L1 = [](){}) {}
)",
Lang_CXX11, "input0.cc");
auto Pattern = cxxRecordDecl(isLambda());
CXXRecordDecl *FromL0 =
FirstDeclMatcher<CXXRecordDecl>().match(FromTU, Pattern);
CXXRecordDecl *FromL1 =
LastDeclMatcher<CXXRecordDecl>().match(FromTU, Pattern);
ASSERT_NE(FromL0, FromL1);
CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
ASSERT_NE(ToL0, ToL1);
}
TEST_P(ASTImporterOptionSpecificTestBase,
LambdasInFunctionParamsAreDifferentiatedWhenMacroIsUsed) {
Decl *FromTU = getTuDecl(
R"(
#define LAMBDA [](){}
template <typename F0, typename F1>
void f(F0 L0 = LAMBDA, F1 L1 = LAMBDA) {}
)",
Lang_CXX11, "input0.cc");
auto Pattern = cxxRecordDecl(isLambda());
CXXRecordDecl *FromL0 =
FirstDeclMatcher<CXXRecordDecl>().match(FromTU, Pattern);
CXXRecordDecl *FromL1 =
LastDeclMatcher<CXXRecordDecl>().match(FromTU, Pattern);
ASSERT_NE(FromL0, FromL1);
Import(FromL0, Lang_CXX11);
Import(FromL1, Lang_CXX11);
CXXRecordDecl *ToL0 = Import(FromL0, Lang_CXX11);
CXXRecordDecl *ToL1 = Import(FromL1, Lang_CXX11);
ASSERT_NE(ToL0, ToL1);
}
TEST_P(ASTImporterOptionSpecificTestBase, ImportAssignedLambda) {
Decl *FromTU = getTuDecl(
R"(
void f() {
auto x = []{} = {}; auto x2 = x;
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX20, "input0.cc");
[ASTImporter] Do not look up lambda classes 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
2019-08-30 18:55:41 +08:00
auto FromF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
// We have only one lambda class.
ASSERT_EQ(
DeclCounter<CXXRecordDecl>().match(FromTU, cxxRecordDecl(isLambda())),
1u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ToF = Import(FromF, Lang_CXX20);
[ASTImporter] Do not look up lambda classes 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
2019-08-30 18:55:41 +08:00
EXPECT_TRUE(ToF);
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// We have only one lambda class after the import.
EXPECT_EQ(DeclCounter<CXXRecordDecl>().match(ToTU, cxxRecordDecl(isLambda())),
1u);
}
TEST_P(ASTImporterOptionSpecificTestBase, ImportDefaultConstructibleLambdas) {
Decl *FromTU = getTuDecl(
R"(
void f() {
auto x = []{} = {};
auto xb = []{} = {};
}
)",
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Lang_CXX20, "input0.cc");
[ASTImporter] Do not look up lambda classes 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
2019-08-30 18:55:41 +08:00
auto FromF = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
// We have two lambda classes.
ASSERT_EQ(
DeclCounter<CXXRecordDecl>().match(FromTU, cxxRecordDecl(isLambda())),
2u);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
FunctionDecl *ToF = Import(FromF, Lang_CXX20);
[ASTImporter] Do not look up lambda classes 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
2019-08-30 18:55:41 +08:00
EXPECT_TRUE(ToF);
TranslationUnitDecl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
// We have two lambda classes after the import.
EXPECT_EQ(DeclCounter<CXXRecordDecl>().match(ToTU, cxxRecordDecl(isLambda())),
2u);
}
[ASTImporter] Implicitly declare parameters for imported ObjCMethodDecls 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
2019-12-07 01:10:23 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImplicitlyDeclareSelf) {
Decl *FromTU = getTuDecl(R"(
__attribute__((objc_root_class))
@interface Root
@end
@interface C : Root
-(void)method;
@end
@implementation C
-(void)method {}
@end
)",
Lang_OBJCXX, "input.mm");
auto *FromMethod = LastDeclMatcher<ObjCMethodDecl>().match(
FromTU, namedDecl(hasName("method")));
ASSERT_TRUE(FromMethod);
auto ToMethod = Import(FromMethod, Lang_OBJCXX);
ASSERT_TRUE(ToMethod);
// Both methods should have their implicit parameters.
EXPECT_TRUE(FromMethod->getSelfDecl() != nullptr);
EXPECT_TRUE(ToMethod->getSelfDecl() != nullptr);
}
[ASTImporter] Support functions with placeholder return types ... Summary: Support functions with placeholder return types even in cases when the type is declared in the body of the function. Example: auto f() { struct X{}; return X(); } Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70819
2019-12-13 00:13:35 +08:00
struct ImportAutoFunctions : ASTImporterOptionSpecificTestBase {};
TEST_P(ImportAutoFunctions, ReturnWithTypedefDeclaredInside) {
Decl *FromTU = getTuDecl(
R"(
auto X = [](long l) {
using int_type = long;
auto dur = 13;
return static_cast<int_type>(dur);
};
)",
Lang_CXX14, "input0.cc");
CXXMethodDecl *From =
FirstDeclMatcher<CXXMethodDecl>().match(FromTU, cxxMethodDecl());
// Explicitly set the return type of the lambda's operator() to the TypeAlias.
// Normally the return type would be the built-in 'long' type. However, there
// are cases when Clang does not use the canonical type and the TypeAlias is
// used. I could not create such an AST from regular source code, it requires
// some special state in the preprocessor. I've found such an AST when Clang
// parsed libcxx/src/filesystem/directory_iterator.cpp, but could not reduce
// that with creduce, because after preprocessing, the AST no longer
// contained the TypeAlias as a return type of the lambda.
ASTContext &Ctx = From->getASTContext();
TypeAliasDecl *FromTA =
FirstDeclMatcher<TypeAliasDecl>().match(FromTU, typeAliasDecl());
QualType TT = Ctx.getTypedefType(FromTA);
const FunctionProtoType *FPT = cast<FunctionProtoType>(From->getType());
QualType NewFunType =
Ctx.getFunctionType(TT, FPT->getParamTypes(), FPT->getExtProtoInfo());
From->setType(NewFunType);
CXXMethodDecl *To = Import(From, Lang_CXX14);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<TypedefType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithStructDeclaredInside) {
Decl *FromTU = getTuDecl(
R"(
auto foo() {
struct X {};
return X();
}
)",
Lang_CXX14, "input0.cc");
FunctionDecl *From =
FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
FunctionDecl *To = Import(From, Lang_CXX14);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithStructDeclaredInside2) {
Decl *FromTU = getTuDecl(
R"(
auto foo() {
struct X {};
return X();
}
)",
Lang_CXX14, "input0.cc");
FunctionDecl *From =
FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
// This time import the type directly.
QualType ToT = ImportType(From->getType(), From, Lang_CXX14);
const FunctionProtoType *FPT = cast<FunctionProtoType>(ToT);
EXPECT_TRUE(isa<AutoType>(FPT->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithTypedefToStructDeclaredInside) {
Decl *FromTU = getTuDecl(
R"(
auto foo() {
struct X {};
using Y = X;
return Y();
}
)",
Lang_CXX14, "input0.cc");
FunctionDecl *From =
FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
FunctionDecl *To = Import(From, Lang_CXX14);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithStructDeclaredNestedInside) {
Decl *FromTU = getTuDecl(
R"(
auto foo() {
struct X { struct Y{}; };
return X::Y();
}
)",
Lang_CXX14, "input0.cc");
FunctionDecl *From =
FirstDeclMatcher<FunctionDecl>().match(FromTU, functionDecl());
FunctionDecl *To = Import(From, Lang_CXX14);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithInternalLambdaType) {
Decl *FromTU = getTuDecl(
R"(
auto f() {
auto l = []() {
struct X {};
return X();
};
return l();
}
)",
Lang_CXX17, "input0.cc");
FunctionDecl *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
FunctionDecl *To = Import(From, Lang_CXX17);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithTypeInIf) {
Decl *FromTU = getTuDecl(
R"(
auto f() {
if (struct X {} x; true)
return X();
else
return X();
}
)",
Lang_CXX17, "input0.cc");
FunctionDecl *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
FunctionDecl *To = Import(From, Lang_CXX17);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithTypeInFor) {
Decl *FromTU = getTuDecl(
R"(
auto f() {
for (struct X {} x;;)
return X();
}
)",
Lang_CXX17, "input0.cc");
FunctionDecl *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
FunctionDecl *To = Import(From, Lang_CXX17);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
TEST_P(ImportAutoFunctions, ReturnWithTypeInSwitch) {
Decl *FromTU = getTuDecl(
R"(
auto f() {
switch (struct X {} x; 10) {
case 10:
return X();
}
}
)",
Lang_CXX17, "input0.cc");
FunctionDecl *From = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("f")));
FunctionDecl *To = Import(From, Lang_CXX17);
EXPECT_TRUE(To);
EXPECT_TRUE(isa<AutoType>(To->getReturnType()));
}
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
struct ImportSourceLocations : ASTImporterOptionSpecificTestBase {};
TEST_P(ImportSourceLocations, PreserveFileIDTreeStructure) {
// Tests that the FileID tree structure (with the links being the include
// chains) is preserved while importing other files (which need to be
// added to this structure with fake include locations.
SourceLocation Location1;
{
auto Pattern = varDecl(hasName("X"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("int X;", Lang_C99, "input0.c");
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Location1 = Import(FromD, Lang_C99)->getLocation();
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
}
SourceLocation Location2;
{
auto Pattern = varDecl(hasName("Y"));
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Decl *FromTU = getTuDecl("int Y;", Lang_C99, "input1.c");
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
auto *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Location2 = Import(FromD, Lang_C99)->getLocation();
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
}
SourceManager &ToSM = ToAST->getSourceManager();
FileID FileID1 = ToSM.getFileID(Location1);
FileID FileID2 = ToSM.getFileID(Location2);
// Check that the imported files look like as if they were included from the
// start of the main file.
SourceLocation FileStart = ToSM.getLocForStartOfFile(ToSM.getMainFileID());
EXPECT_NE(FileID1, ToSM.getMainFileID());
EXPECT_NE(FileID2, ToSM.getMainFileID());
EXPECT_EQ(ToSM.getIncludeLoc(FileID1), FileStart);
EXPECT_EQ(ToSM.getIncludeLoc(FileID2), FileStart);
// Let the SourceManager check the order of the locations. The order should
// be the order in which the declarations are imported.
EXPECT_TRUE(ToSM.isBeforeInTranslationUnit(Location1, Location2));
EXPECT_FALSE(ToSM.isBeforeInTranslationUnit(Location2, Location1));
}
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
TEST_P(ImportSourceLocations, NormalFileBuffer) {
// Test importing normal file buffers.
std::string Path = "input0.c";
std::string Source = "int X;";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl(Source, Lang_C99, Path);
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
SourceLocation ImportedLoc;
{
// Import the VarDecl to trigger the importing of the FileID.
auto Pattern = varDecl(hasName("X"));
VarDecl *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ImportedLoc = Import(FromD, Lang_C99)->getLocation();
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
}
// Make sure the imported buffer has the original contents.
SourceManager &ToSM = ToAST->getSourceManager();
FileID ImportedID = ToSM.getFileID(ImportedLoc);
clang-{tools,unittests}: Stop using SourceManager::getBuffer, NFC Update clang-tools-extra, clang/tools, clang/unittests to migrate from `SourceManager::getBuffer`, which returns an always dereferenceable `MemoryBuffer*`, to `getBufferOrNone` or `getBufferOrFake`, both of which return a `MemoryBufferRef`, depending on whether the call site was checking for validity of the buffer. No functionality change intended. Differential Revision: https://reviews.llvm.org/D89416
2020-10-15 02:36:00 +08:00
EXPECT_EQ(Source,
ToSM.getBufferOrFake(ImportedID, SourceLocation()).getBuffer());
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
}
TEST_P(ImportSourceLocations, OverwrittenFileBuffer) {
// Test importing overwritten file buffers.
std::string Path = "input0.c";
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl("int X;", Lang_C99, Path);
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
// Overwrite the file buffer for our input file with new content.
const std::string Contents = "overwritten contents";
SourceLocation ImportedLoc;
{
SourceManager &FromSM = FromTU->getASTContext().getSourceManager();
clang::FileManager &FM = FromSM.getFileManager();
const clang::FileEntry &FE =
*FM.getVirtualFile(Path, static_cast<off_t>(Contents.size()), 0);
llvm::SmallVector<char, 64> Buffer;
Buffer.append(Contents.begin(), Contents.end());
auto FileContents =
std::make_unique<llvm::SmallVectorMemoryBuffer>(std::move(Buffer), Path);
FromSM.overrideFileContents(&FE, std::move(FileContents));
// Import the VarDecl to trigger the importing of the FileID.
auto Pattern = varDecl(hasName("X"));
VarDecl *FromD = FirstDeclMatcher<VarDecl>().match(FromTU, Pattern);
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
ImportedLoc = Import(FromD, Lang_C99)->getLocation();
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
}
// Make sure the imported buffer has the overwritten contents.
SourceManager &ToSM = ToAST->getSourceManager();
FileID ImportedID = ToSM.getFileID(ImportedLoc);
EXPECT_EQ(Contents,
clang-{tools,unittests}: Stop using SourceManager::getBuffer, NFC Update clang-tools-extra, clang/tools, clang/unittests to migrate from `SourceManager::getBuffer`, which returns an always dereferenceable `MemoryBuffer*`, to `getBufferOrNone` or `getBufferOrFake`, both of which return a `MemoryBufferRef`, depending on whether the call site was checking for validity of the buffer. No functionality change intended. Differential Revision: https://reviews.llvm.org/D89416
2020-10-15 02:36:00 +08:00
ToSM.getBufferOrFake(ImportedID, SourceLocation()).getBuffer());
[ASTImporter] Also import overwritten file buffers Summary: Overwritten file buffers are at the moment ignored when importing and instead only the underlying file buffer is imported. This patch fixes this by not going to the underlying file entry if the file has an overwritten buffer. Reviewers: martong, a.sidorin, shafik Reviewed By: martong, shafik Subscribers: rnkovacs Differential Revision: https://reviews.llvm.org/D78086
2020-04-27 16:06:56 +08:00
}
[ASTImporter] Improved import of AlignedAttr. Summary: It is not enough to clone the attributes at import. They can contain reference to objects that should be imported. This work is done now for AlignedAttr. Reviewers: martong, a.sidorin, shafik Reviewed By: shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D75048
2020-02-28 15:32:32 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportExprOfAlignmentAttr) {
// Test if import of these packed and aligned attributes does not trigger an
// error situation where source location from 'From' context is referenced in
// 'To' context through evaluation of the alignof attribute.
// This happens if the 'alignof(A)' expression is not imported correctly.
Decl *FromTU = getTuDecl(
R"(
struct __attribute__((packed)) A { int __attribute__((aligned(8))) X; };
struct alignas(alignof(A)) S {};
)",
Lang_CXX11, "input.cc");
auto *FromD = FirstDeclMatcher<CXXRecordDecl>().match(
FromTU, cxxRecordDecl(hasName("S"), unless(isImplicit())));
ASSERT_TRUE(FromD);
auto *ToD = Import(FromD, Lang_CXX11);
ASSERT_TRUE(ToD);
auto *FromAttr = FromD->getAttr<AlignedAttr>();
auto *ToAttr = ToD->getAttr<AlignedAttr>();
EXPECT_EQ(FromAttr->isInherited(), ToAttr->isInherited());
EXPECT_EQ(FromAttr->isPackExpansion(), ToAttr->isPackExpansion());
EXPECT_EQ(FromAttr->isImplicit(), ToAttr->isImplicit());
EXPECT_EQ(FromAttr->getSyntax(), ToAttr->getSyntax());
EXPECT_EQ(FromAttr->getSemanticSpelling(), ToAttr->getSemanticSpelling());
EXPECT_TRUE(ToAttr->getAlignmentExpr());
auto *ToA = FirstDeclMatcher<CXXRecordDecl>().match(
ToD->getTranslationUnitDecl(),
cxxRecordDecl(hasName("A"), unless(isImplicit())));
// Ensure that 'struct A' was imported (through reference from attribute of
// 'S').
EXPECT_TRUE(ToA);
}
[ASTImporter] Fix crash caused by unimported type of FromatAttr During the import of FormatAttrs we forgot to import the type (e.g `__scanf__`) of the attribute. This caused a segfault when we wanted to traverse the AST (e.g. by the dump() method). Differential Revision: https://reviews.llvm.org/D89319
2020-10-13 21:57:37 +08:00
TEST_P(ASTImporterOptionSpecificTestBase, ImportFormatAttr) {
Decl *FromTU = getTuDecl(
R"(
int foo(const char * fmt, ...)
Revert "[ASTImporter] Fix crash caused by unset AttributeSpellingListIndex" This broke the GreenDragon build, due to the following error while running TestImportBuiltinFileID: ``` Ignored/unknown shouldn't get here UNREACHABLE executed at tools/clang/include/clang/Sema/AttrSpellingListIndex.inc:13! ``` See http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/24213/ This reverts commit 73c6beb2f7053fe8b5150072c2b5cd930de38a22. This reverts https://reviews.llvm.org/D89318
2020-10-15 08:19:22 +08:00
__attribute__ ((__format__ (__scanf__, 1, 2)));
[ASTImporter] Fix crash caused by unimported type of FromatAttr During the import of FormatAttrs we forgot to import the type (e.g `__scanf__`) of the attribute. This caused a segfault when we wanted to traverse the AST (e.g. by the dump() method). Differential Revision: https://reviews.llvm.org/D89319
2020-10-13 21:57:37 +08:00
)",
Lang_CXX03, "input.cc");
auto *FromD = FirstDeclMatcher<FunctionDecl>().match(
FromTU, functionDecl(hasName("foo")));
ASSERT_TRUE(FromD);
auto *ToD = Import(FromD, Lang_CXX03);
ASSERT_TRUE(ToD);
ToD->dump(); // Should not crash!
auto *FromAttr = FromD->getAttr<FormatAttr>();
auto *ToAttr = ToD->getAttr<FormatAttr>();
EXPECT_EQ(FromAttr->isInherited(), ToAttr->isInherited());
EXPECT_EQ(FromAttr->isPackExpansion(), ToAttr->isPackExpansion());
EXPECT_EQ(FromAttr->isImplicit(), ToAttr->isImplicit());
EXPECT_EQ(FromAttr->getSyntax(), ToAttr->getSyntax());
EXPECT_EQ(FromAttr->getAttributeSpellingListIndex(),
ToAttr->getAttributeSpellingListIndex());
EXPECT_EQ(FromAttr->getType()->getName(), ToAttr->getType()->getName());
}
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
template <typename T>
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
auto ExtendWithOptions(const T &Values, const std::vector<std::string> &Args) {
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
auto Copy = Values;
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
for (std::vector<std::string> &ArgV : Copy) {
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
for (const std::string &Arg : Args) {
ArgV.push_back(Arg);
}
}
return ::testing::ValuesIn(Copy);
}
[ASTImporter] Fix handling of not defined FromRecord in ImportContext(...) In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not defined will start the definition of a ToRecord but from what I can tell at least one of the paths though here don't ensure we complete the definition. For a RecordDecl this can be problematic since this means we won’t import base classes and we won’t have any of the methods or types we inherit from these bases. Differential Revision: https://reviews.llvm.org/D78000
2020-04-24 06:16:34 +08:00
struct ImportWithExternalSource : ASTImporterOptionSpecificTestBase {
ImportWithExternalSource() {
Creator = [](ASTContext &ToContext, FileManager &ToFileManager,
ASTContext &FromContext, FileManager &FromFileManager,
bool MinimalImport,
const std::shared_ptr<ASTImporterSharedState> &SharedState) {
return new ASTImporter(ToContext, ToFileManager, FromContext,
FromFileManager, MinimalImport,
// We use the regular lookup.
/*SharedState=*/nullptr);
};
}
};
/// An ExternalASTSource that keeps track of the tags is completed.
struct SourceWithCompletedTagList : clang::ExternalASTSource {
std::vector<clang::TagDecl *> &CompletedTags;
SourceWithCompletedTagList(std::vector<clang::TagDecl *> &CompletedTags)
: CompletedTags(CompletedTags) {}
void CompleteType(TagDecl *Tag) override {
auto *Record = cast<CXXRecordDecl>(Tag);
Record->startDefinition();
Record->completeDefinition();
CompletedTags.push_back(Tag);
}
[clang][NFC] Properly fix a GCC warning in ASTImporterTest.cpp Follow up to c9b45ce1fd97531c228e092bedee719b971f82a3 which just defined the function instead of just 'using' the function from the base class (thanks David).
2020-08-26 22:37:35 +08:00
using clang::ExternalASTSource::CompleteType;
[ASTImporter] Fix handling of not defined FromRecord in ImportContext(...) In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not defined will start the definition of a ToRecord but from what I can tell at least one of the paths though here don't ensure we complete the definition. For a RecordDecl this can be problematic since this means we won’t import base classes and we won’t have any of the methods or types we inherit from these bases. Differential Revision: https://reviews.llvm.org/D78000
2020-04-24 06:16:34 +08:00
};
TEST_P(ImportWithExternalSource, CompleteRecordBeforeImporting) {
// Create an empty TU.
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
TranslationUnitDecl *FromTU = getTuDecl("", Lang_CXX03, "input.cpp");
[ASTImporter] Fix handling of not defined FromRecord in ImportContext(...) In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not defined will start the definition of a ToRecord but from what I can tell at least one of the paths though here don't ensure we complete the definition. For a RecordDecl this can be problematic since this means we won’t import base classes and we won’t have any of the methods or types we inherit from these bases. Differential Revision: https://reviews.llvm.org/D78000
2020-04-24 06:16:34 +08:00
// Create and add the test ExternalASTSource.
std::vector<clang::TagDecl *> CompletedTags;
IntrusiveRefCntPtr<ExternalASTSource> source =
new SourceWithCompletedTagList(CompletedTags);
clang::ASTContext &Context = FromTU->getASTContext();
Context.setExternalSource(std::move(source));
// Create a dummy class by hand with external lexical storage.
IdentifierInfo &Ident = Context.Idents.get("test_class");
auto *Record = CXXRecordDecl::Create(
Context, TTK_Class, FromTU, SourceLocation(), SourceLocation(), &Ident);
Record->setHasExternalLexicalStorage();
FromTU->addDecl(Record);
// Do a minimal import of the created class.
EXPECT_EQ(0U, CompletedTags.size());
Renamed Lang_C to Lang_C99, Lang_CXX to Lang_CXX03, and 2a to 20 Summary: I think we would be better off with tests explicitly specifying the language mode. Right now Lang_C means C99, but reads as "any C version", or as "unspecified C version". I also changed '-std=c++98' to '-std=c++03' because they are aliases (so there is no difference in practice), because Clang implements C++03 rules in practice, and because 03 makes a nice sortable progression between 03, 11, 14, 17, 20. Reviewers: shafik, hlopko Reviewed By: hlopko Subscribers: jfb, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D81000
2020-06-02 22:10:39 +08:00
Import(Record, Lang_CXX03);
[ASTImporter] Fix handling of not defined FromRecord in ImportContext(...) In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not defined will start the definition of a ToRecord but from what I can tell at least one of the paths though here don't ensure we complete the definition. For a RecordDecl this can be problematic since this means we won’t import base classes and we won’t have any of the methods or types we inherit from these bases. Differential Revision: https://reviews.llvm.org/D78000
2020-04-24 06:16:34 +08:00
EXPECT_EQ(0U, CompletedTags.size());
// Import the definition of the created class.
llvm::Error Err = findFromTU(Record)->Importer->ImportDefinition(Record);
EXPECT_FALSE((bool)Err);
consumeError(std::move(Err));
// Make sure the class was completed once.
EXPECT_EQ(1U, CompletedTags.size());
EXPECT_EQ(Record, CompletedTags.front());
}
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterLookupTableTest,
DefaultTestValuesForRunOptions, );
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportPath,
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
::testing::Values(std::vector<std::string>()), );
[ASTImporter] Mark erroneous nodes in from ctx 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
2019-07-01 22:19:53 +08:00
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportExpr,
DefaultTestValuesForRunOptions, );
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFixedPointExpr,
ExtendWithOptions(DefaultTestArrayForRunOptions,
Rename APIs in unittests/AST/Language.h in preparation to share them Summary: Declaring these helpers in the ast_matcher namespace in the clangAST unit test seems inappropriate -- neither these helpers, nor clangAST have anything to do with AST matchers. Therefore, I moved these helpers to the clang namespace. Declaring another typedef called "ArgVector" is not a good idea -- we already have both "ArgVector", "ArgsVector", and "ArgList". I expanded it into the underlying type. Declaring another enum called "Language" is not a good idea because we arleady have the "clang::Language" enum. I renamed it to "TestLanguage". Similarly, I renamed "getBasicRunOptionsForLanguage" to "getCommandLineArgsForTesting" to explain the semantics better (what are "run options"?) and not repeat types in the function name ("ForLanguage"). Reviewers: shafik, rengolin, sammccall Reviewed By: sammccall Subscribers: gribozavr2, sammccall, martong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D80786
2020-05-29 20:12:51 +08:00
std::vector<std::string>{
"-ffixed-point"}), );
[ASTImporter] Add support for importing fixed point literals Summary: This patch adds support for importing fixed point literals, following up to https://reviews.llvm.org/D46915 specifically for importing AST. Reviewers: martong, leonardchan, ebevhan, a.sidorin, shafik Reviewed By: martong Subscribers: balazske, rnkovacs, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77721
2020-04-06 21:22:35 +08:00
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportType,
DefaultTestValuesForRunOptions, );
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportDecl,
DefaultTestValuesForRunOptions, );
[ASTImporter] Refactor unittests to be able to parameterize them in a more flexible way 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
2019-02-08 00:52:48 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ASTImporterOptionSpecificTestBase,
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ErrorHandlingTest,
DefaultTestValuesForRunOptions, );
[ASTImporter] Add an ImportImpl method to allow customizing Import behavior. 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
2019-04-30 05:02:35 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, RedirectingImporterTest,
DefaultTestValuesForRunOptions, );
[ASTImporter] Add ms compatibility to tests which use the TestBase 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
2018-06-25 21:04:37 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFunctions,
DefaultTestValuesForRunOptions, );
Do not try to remove invisible Decls from DeclContext llvm-svn: 332699
2018-05-18 17:08:47 +08:00
[ASTImporter] Support functions with placeholder return types ... Summary: Support functions with placeholder return types even in cases when the type is declared in the body of the function. Example: auto f() { struct X{}; return X(); } Reviewers: balazske, a_sidorin, a.sidorin, shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, teemperor, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D70819
2019-12-13 00:13:35 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportAutoFunctions,
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFunctionTemplates,
[ASTImporter] Find previous friend function template Reviewers: a_sidorin, shafik, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57910 llvm-svn: 354267
2019-02-18 21:09:27 +08:00
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFriendFunctionTemplates,
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix name conflict handling with different strategies 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
2019-08-27 19:36:10 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportClasses,
[ASTImporter] Do not import FunctionTemplateDecl in record twice. 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
2019-08-07 20:40:17 +08:00
DefaultTestValuesForRunOptions, );
[ASTImporter] Add importer specific lookup 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
2018-12-17 21:53:12 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFriendFunctions,
[ASTImporter] Fix redecl chain of classes and class templates 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
2018-12-17 20:42:12 +08:00
DefaultTestValuesForRunOptions, );
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportFriendClasses,
DefaultTestValuesForRunOptions, );
Re-apply: [ASTImporter] Import the whole redecl chain of functions 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
2018-06-27 21:32:50 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests,
ImportFunctionTemplateSpecializations,
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix import of VarDecl init 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
2018-09-17 20:04:52 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportImplicitMethods,
DefaultTestValuesForRunOptions, );
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportVariables,
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix LLDB lookup in transparent ctx and with ext src 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
2019-07-17 21:47:46 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, LLDBLookupTest,
DefaultTestValuesForRunOptions, );
[ASTImporter] Prevent the ASTImporter from creating multiple main FileIDs. Summary: When importing the main FileID the ASTImporter currently gives it no include location. This means that any SourceLocations produced for this FileID look to Clang as if they are coming from the main FileID (as the main FileID has no include location). Clang seems to expect that there is only one main FileID in one translation unit (which makes sense during normal compilation), so this behavior leads to several problems when producing diagnostics, one being that when calling `SourceManager::isBeforeInTranslationUnit` on two SourceLocations that come from two different ASTContext instances, Clang fails to sort the SourceLocations as the include chains of the FileIDs don't end up in a single FileID. This causes that Clang crashes with "Unsortable locations found" in this function. This patch gives any imported main FileIDs the main FileID of the To ASTContext as its include location. This allows Clang to sort all imported SourceLocations as now all include chains point to the main FileID of the To ASTContext. The exact include location is currently set to the start of the To main file (just because that should always be a valid SourceLocation). Reviewers: martong, a_sidorin, a.sidorin, shafik, balazske Reviewed By: martong, a_sidorin, shafik Subscribers: balazske, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D74542
2020-02-18 02:43:33 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportSourceLocations,
DefaultTestValuesForRunOptions, );
[ASTImporter] Fix handling of not defined FromRecord in ImportContext(...) In ImportContext(…) we may call into CompleteDecl(…) which if FromRecrord is not defined will start the definition of a ToRecord but from what I can tell at least one of the paths though here don't ensure we complete the definition. For a RecordDecl this can be problematic since this means we won’t import base classes and we won’t have any of the methods or types we inherit from these bases. Differential Revision: https://reviews.llvm.org/D78000
2020-04-24 06:16:34 +08:00
INSTANTIATE_TEST_CASE_P(ParameterizedTests, ImportWithExternalSource,
DefaultTestValuesForRunOptions, );
[ASTImporter] Implement some expression-related AST node import. Introduce ASTImporter unit test framework. Fix a memory leak introduced in cf8ccff5: an array is allocated in ImportArray and never freed. Support new node kinds: - GCCAsmStmt - AddrLabelExpr - AtomicExpr - CompoundLiteralExpr - CXXBoolLiteralExpr - CXXNullPtrLiteralExpr - CXXThisExpr - DesignatedInitExpr - GNUNullExpr - ImplicitValueInitExpr - InitListExpr - OpaqueValueExpr - PredefinedExpr - ParenListExpr - StmtExpr - VAArgExpr - BinaryConditionalOperator - ConditionalOperator - FloatingLiteral - StringLiteral - InjectedClassNameType - TemplateTypeParmType - LabelDecl Patch by Aleksei Sidorin! Differential Revision: http://reviews.llvm.org/D14286 llvm-svn: 266292
2016-04-14 19:51:27 +08:00
} // end namespace ast_matchers
} // end namespace clang