llvm-project/clang/lib/AST/ExternalASTMerger.cpp

455 lines
18 KiB
C++
Raw Normal View History

//===- ExternalASTMerger.cpp - Merging External AST Interface ---*- C++ -*-===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// This file implements the ExternalASTMerger, which vends a combination of
// ASTs from several different ASTContext/FileManager pairs
//
//===----------------------------------------------------------------------===//
#include "clang/AST/ASTContext.h"
#include "clang/AST/Decl.h"
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
#include "clang/AST/DeclCXX.h"
#include "clang/AST/DeclObjC.h"
#include "clang/AST/DeclTemplate.h"
#include "clang/AST/ExternalASTMerger.h"
using namespace clang;
namespace {
template <typename T> struct Source {
T t;
Source(T t) : t(t) {}
operator T() { return t; }
template <typename U = T> U &get() { return t; }
template <typename U = T> const U &get() const { return t; }
template <typename U> operator Source<U>() { return Source<U>(t); }
};
typedef std::pair<Source<NamedDecl *>, ASTImporter *> Candidate;
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
/// For the given DC, return the DC that is safe to perform lookups on. This is
/// the DC we actually want to work with most of the time.
const DeclContext *CanonicalizeDC(const DeclContext *DC) {
if (isa<LinkageSpecDecl>(DC))
return DC->getRedeclContext();
return DC;
}
Source<const DeclContext *>
LookupSameContext(Source<TranslationUnitDecl *> SourceTU, const DeclContext *DC,
ASTImporter &ReverseImporter) {
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
DC = CanonicalizeDC(DC);
if (DC->isTranslationUnit()) {
return SourceTU;
}
Source<const DeclContext *> SourceParentDC =
LookupSameContext(SourceTU, DC->getParent(), ReverseImporter);
if (!SourceParentDC) {
// If we couldn't find the parent DC in this TranslationUnit, give up.
return nullptr;
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
auto *ND = cast<NamedDecl>(DC);
DeclarationName Name = ND->getDeclName();
auto SourceNameOrErr = ReverseImporter.Import(Name);
if (!SourceNameOrErr) {
llvm::consumeError(SourceNameOrErr.takeError());
return nullptr;
}
Source<DeclarationName> SourceName = *SourceNameOrErr;
DeclContext::lookup_result SearchResult =
SourceParentDC.get()->lookup(SourceName.get());
size_t SearchResultSize = SearchResult.size();
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (SearchResultSize == 0 || SearchResultSize > 1) {
// There are two cases here. First, we might not find the name.
// We might also find multiple copies, in which case we have no
// guarantee that the one we wanted is the one we pick. (E.g.,
// if we have two specializations of the same template it is
// very hard to determine which is the one you want.)
//
// The Origins map fixes this problem by allowing the origin to be
// explicitly recorded, so we trigger that recording by returning
// nothing (rather than a possibly-inaccurate guess) here.
return nullptr;
} else {
NamedDecl *SearchResultDecl = SearchResult[0];
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (isa<DeclContext>(SearchResultDecl) &&
SearchResultDecl->getKind() == DC->getDeclKind())
return cast<DeclContext>(SearchResultDecl)->getPrimaryContext();
return nullptr; // This type of lookup is unsupported
}
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
/// A custom implementation of ASTImporter, for ExternalASTMerger's purposes.
///
/// There are several modifications:
///
/// - It enables lazy lookup (via the HasExternalLexicalStorage flag and a few
/// others), which instructs Clang to refer to ExternalASTMerger. Also, it
/// forces MinimalImport to true, which is necessary to make this work.
/// - It maintains a reverse importer for use with names. This allows lookup of
/// arbitrary names in the source context.
/// - It updates the ExternalASTMerger's origin map as needed whenever a
/// it sees a DeclContext.
class LazyASTImporter : public ASTImporter {
private:
ExternalASTMerger &Parent;
ASTImporter Reverse;
const ExternalASTMerger::OriginMap &FromOrigins;
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
llvm::raw_ostream &logs() { return Parent.logs(); }
public:
LazyASTImporter(ExternalASTMerger &_Parent, ASTContext &ToContext,
FileManager &ToFileManager, ASTContext &FromContext,
FileManager &FromFileManager,
const ExternalASTMerger::OriginMap &_FromOrigins)
: ASTImporter(ToContext, ToFileManager, FromContext, FromFileManager,
/*MinimalImport=*/true),
Parent(_Parent), Reverse(FromContext, FromFileManager, ToContext,
ToFileManager, /*MinimalImport=*/true), FromOrigins(_FromOrigins) {}
/// Whenever a DeclContext is imported, ensure that ExternalASTSource's origin
/// map is kept up to date. Also set the appropriate flags.
void Imported(Decl *From, Decl *To) override {
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (auto *ToDC = dyn_cast<DeclContext>(To)) {
const bool LoggingEnabled = Parent.LoggingEnabled();
if (LoggingEnabled)
logs() << "(ExternalASTMerger*)" << (void*)&Parent
<< " imported (DeclContext*)" << (void*)ToDC
<< ", (ASTContext*)" << (void*)&getToContext()
<< " from (DeclContext*)" << (void*)llvm::cast<DeclContext>(From)
<< ", (ASTContext*)" << (void*)&getFromContext()
<< "\n";
Source<DeclContext *> FromDC(
cast<DeclContext>(From)->getPrimaryContext());
if (FromOrigins.count(FromDC) &&
Parent.HasImporterForOrigin(*FromOrigins.at(FromDC).AST)) {
if (LoggingEnabled)
logs() << "(ExternalASTMerger*)" << (void*)&Parent
<< " forced origin (DeclContext*)"
<< (void*)FromOrigins.at(FromDC).DC
<< ", (ASTContext*)"
<< (void*)FromOrigins.at(FromDC).AST
<< "\n";
Parent.ForceRecordOrigin(ToDC, FromOrigins.at(FromDC));
} else {
if (LoggingEnabled)
logs() << "(ExternalASTMerger*)" << (void*)&Parent
<< " maybe recording origin (DeclContext*)" << (void*)FromDC
<< ", (ASTContext*)" << (void*)&getFromContext()
<< "\n";
Parent.MaybeRecordOrigin(ToDC, {FromDC, &getFromContext()});
}
}
if (auto *ToTag = dyn_cast<TagDecl>(To)) {
ToTag->setHasExternalLexicalStorage();
ToTag->getPrimaryContext()->setMustBuildLookupTable();
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
assert(Parent.CanComplete(ToTag));
} else if (auto *ToNamespace = dyn_cast<NamespaceDecl>(To)) {
ToNamespace->setHasExternalVisibleStorage();
assert(Parent.CanComplete(ToNamespace));
} else if (auto *ToContainer = dyn_cast<ObjCContainerDecl>(To)) {
ToContainer->setHasExternalLexicalStorage();
ToContainer->getPrimaryContext()->setMustBuildLookupTable();
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
assert(Parent.CanComplete(ToContainer));
}
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
ASTImporter &GetReverse() { return Reverse; }
};
bool HasDeclOfSameType(llvm::ArrayRef<Candidate> Decls, const Candidate &C) {
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (isa<FunctionDecl>(C.first.get()))
return false;
return llvm::any_of(Decls, [&](const Candidate &D) {
return C.first.get()->getKind() == D.first.get()->getKind();
});
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
} // end namespace
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
ASTImporter &ExternalASTMerger::ImporterForOrigin(ASTContext &OriginContext) {
for (const std::unique_ptr<ASTImporter> &I : Importers)
if (&I->getFromContext() == &OriginContext)
return *I;
llvm_unreachable("We should have an importer for this origin!");
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
namespace {
LazyASTImporter &LazyImporterForOrigin(ExternalASTMerger &Merger,
ASTContext &OriginContext) {
return static_cast<LazyASTImporter &>(
Merger.ImporterForOrigin(OriginContext));
}
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
bool ExternalASTMerger::HasImporterForOrigin(ASTContext &OriginContext) {
for (const std::unique_ptr<ASTImporter> &I : Importers)
if (&I->getFromContext() == &OriginContext)
return true;
return false;
}
template <typename CallbackType>
void ExternalASTMerger::ForEachMatchingDC(const DeclContext *DC,
CallbackType Callback) {
if (Origins.count(DC)) {
ExternalASTMerger::DCOrigin Origin = Origins[DC];
LazyASTImporter &Importer = LazyImporterForOrigin(*this, *Origin.AST);
Callback(Importer, Importer.GetReverse(), Origin.DC);
} else {
bool DidCallback = false;
for (const std::unique_ptr<ASTImporter> &Importer : Importers) {
Source<TranslationUnitDecl *> SourceTU =
Importer->getFromContext().getTranslationUnitDecl();
ASTImporter &Reverse =
static_cast<LazyASTImporter *>(Importer.get())->GetReverse();
if (auto SourceDC = LookupSameContext(SourceTU, DC, Reverse)) {
DidCallback = true;
if (Callback(*Importer, Reverse, SourceDC))
break;
}
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (!DidCallback && LoggingEnabled())
logs() << "(ExternalASTMerger*)" << (void*)this
<< " asserting for (DeclContext*)" << (const void*)DC
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
<< ", (ASTContext*)" << (void*)&Target.AST
<< "\n";
assert(DidCallback && "Couldn't find a source context matching our DC");
}
}
void ExternalASTMerger::CompleteType(TagDecl *Tag) {
assert(Tag->hasExternalLexicalStorage());
ForEachMatchingDC(Tag, [&](ASTImporter &Forward, ASTImporter &Reverse,
Source<const DeclContext *> SourceDC) -> bool {
auto *SourceTag = const_cast<TagDecl *>(cast<TagDecl>(SourceDC.get()));
if (SourceTag->hasExternalLexicalStorage())
SourceTag->getASTContext().getExternalSource()->CompleteType(SourceTag);
if (!SourceTag->getDefinition())
return false;
[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
Forward.MapImported(SourceTag, Tag);
if (llvm::Error Err = Forward.ImportDefinition(SourceTag))
llvm::consumeError(std::move(Err));
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
Tag->setCompleteDefinition(SourceTag->isCompleteDefinition());
return true;
});
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
void ExternalASTMerger::CompleteType(ObjCInterfaceDecl *Interface) {
assert(Interface->hasExternalLexicalStorage());
ForEachMatchingDC(
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
Interface, [&](ASTImporter &Forward, ASTImporter &Reverse,
Source<const DeclContext *> SourceDC) -> bool {
auto *SourceInterface = const_cast<ObjCInterfaceDecl *>(
cast<ObjCInterfaceDecl>(SourceDC.get()));
if (SourceInterface->hasExternalLexicalStorage())
SourceInterface->getASTContext().getExternalSource()->CompleteType(
SourceInterface);
if (!SourceInterface->getDefinition())
return false;
[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
Forward.MapImported(SourceInterface, Interface);
if (llvm::Error Err = Forward.ImportDefinition(SourceInterface))
llvm::consumeError(std::move(Err));
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
return true;
});
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
bool ExternalASTMerger::CanComplete(DeclContext *Interface) {
assert(Interface->hasExternalLexicalStorage() ||
Interface->hasExternalVisibleStorage());
bool FoundMatchingDC = false;
ForEachMatchingDC(Interface,
[&](ASTImporter &Forward, ASTImporter &Reverse,
Source<const DeclContext *> SourceDC) -> bool {
FoundMatchingDC = true;
return true;
});
return FoundMatchingDC;
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
namespace {
bool IsSameDC(const DeclContext *D1, const DeclContext *D2) {
if (isa<ObjCContainerDecl>(D1) && isa<ObjCContainerDecl>(D2))
return true; // There are many cases where Objective-C is ambiguous.
if (auto *T1 = dyn_cast<TagDecl>(D1))
if (auto *T2 = dyn_cast<TagDecl>(D2))
if (T1->getFirstDecl() == T2->getFirstDecl())
return true;
return D1 == D2 || D1 == CanonicalizeDC(D2);
}
}
void ExternalASTMerger::MaybeRecordOrigin(const DeclContext *ToDC,
DCOrigin Origin) {
LazyASTImporter &Importer = LazyImporterForOrigin(*this, *Origin.AST);
ASTImporter &Reverse = Importer.GetReverse();
Source<const DeclContext *> FoundFromDC =
LookupSameContext(Origin.AST->getTranslationUnitDecl(), ToDC, Reverse);
const bool DoRecord = !FoundFromDC || !IsSameDC(FoundFromDC.get(), Origin.DC);
if (DoRecord)
RecordOriginImpl(ToDC, Origin, Importer);
if (LoggingEnabled())
logs() << "(ExternalASTMerger*)" << (void*)this
<< (DoRecord ? " decided " : " decided NOT")
<< " to record origin (DeclContext*)" << (void*)Origin.DC
<< ", (ASTContext*)" << (void*)&Origin.AST
<< "\n";
}
void ExternalASTMerger::ForceRecordOrigin(const DeclContext *ToDC,
DCOrigin Origin) {
RecordOriginImpl(ToDC, Origin, ImporterForOrigin(*Origin.AST));
}
void ExternalASTMerger::RecordOriginImpl(const DeclContext *ToDC, DCOrigin Origin,
ASTImporter &Importer) {
Origins[ToDC] = Origin;
[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
Importer.ASTImporter::MapImported(cast<Decl>(Origin.DC), const_cast<Decl*>(cast<Decl>(ToDC)));
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
}
ExternalASTMerger::ExternalASTMerger(const ImporterTarget &Target,
llvm::ArrayRef<ImporterSource> Sources) : LogStream(&llvm::nulls()), Target(Target) {
AddSources(Sources);
}
void ExternalASTMerger::AddSources(llvm::ArrayRef<ImporterSource> Sources) {
for (const ImporterSource &S : Sources) {
assert(&S.AST != &Target.AST);
Importers.push_back(llvm::make_unique<LazyASTImporter>(
*this, Target.AST, Target.FM, S.AST, S.FM, S.OM));
}
}
void ExternalASTMerger::RemoveSources(llvm::ArrayRef<ImporterSource> Sources) {
if (LoggingEnabled())
for (const ImporterSource &S : Sources)
logs() << "(ExternalASTMerger*)" << (void*)this
<< " removing source (ASTContext*)" << (void*)&S.AST
<< "\n";
Importers.erase(
std::remove_if(Importers.begin(), Importers.end(),
[&Sources](std::unique_ptr<ASTImporter> &Importer) -> bool {
for (const ImporterSource &S : Sources) {
if (&Importer->getFromContext() == &S.AST)
return true;
}
return false;
}),
Importers.end());
for (OriginMap::iterator OI = Origins.begin(), OE = Origins.end(); OI != OE; ) {
std::pair<const DeclContext *, DCOrigin> Origin = *OI;
bool Erase = false;
for (const ImporterSource &S : Sources) {
if (&S.AST == Origin.second.AST) {
Erase = true;
break;
}
}
if (Erase)
OI = Origins.erase(OI);
else
++OI;
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
}
template <typename DeclTy>
static bool importSpecializations(DeclTy *D, ASTImporter *Importer) {
for (auto *Spec : D->specializations()) {
auto ImportedSpecOrError = Importer->Import(Spec);
if (!ImportedSpecOrError) {
llvm::consumeError(ImportedSpecOrError.takeError());
return true;
}
}
return false;
}
/// Imports specializations from template declarations that can be specialized.
static bool importSpecializationsIfNeeded(Decl *D, ASTImporter *Importer) {
if (!isa<TemplateDecl>(D))
return false;
if (auto *FunctionTD = dyn_cast<FunctionTemplateDecl>(D))
return importSpecializations(FunctionTD, Importer);
else if (auto *ClassTD = dyn_cast<ClassTemplateDecl>(D))
return importSpecializations(ClassTD, Importer);
else if (auto *VarTD = dyn_cast<VarTemplateDecl>(D))
return importSpecializations(VarTD, Importer);
return false;
}
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
bool ExternalASTMerger::FindExternalVisibleDeclsByName(const DeclContext *DC,
DeclarationName Name) {
llvm::SmallVector<NamedDecl *, 1> Decls;
llvm::SmallVector<Candidate, 4> Candidates;
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
auto FilterFoundDecl = [&Candidates](const Candidate &C) {
if (!HasDeclOfSameType(Candidates, C))
Candidates.push_back(C);
};
ForEachMatchingDC(DC,
[&](ASTImporter &Forward, ASTImporter &Reverse,
Source<const DeclContext *> SourceDC) -> bool {
auto FromNameOrErr = Reverse.Import(Name);
if (!FromNameOrErr) {
llvm::consumeError(FromNameOrErr.takeError());
return false;
}
DeclContextLookupResult Result =
SourceDC.get()->lookup(*FromNameOrErr);
for (NamedDecl *FromD : Result) {
FilterFoundDecl(std::make_pair(FromD, &Forward));
}
return false;
});
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
if (Candidates.empty())
return false;
Decls.reserve(Candidates.size());
for (const Candidate &C : Candidates) {
Decl *LookupRes = C.first.get();
ASTImporter *Importer = C.second;
auto NDOrErr = Importer->Import(LookupRes);
assert(NDOrErr);
(void)static_cast<bool>(NDOrErr);
NamedDecl *ND = cast_or_null<NamedDecl>(*NDOrErr);
assert(ND);
// If we don't import specialization, they are not available via lookup
// because the lookup result is imported TemplateDecl and it does not
// reference its specializations until they are imported explicitly.
bool IsSpecImportFailed =
importSpecializationsIfNeeded(LookupRes, Importer);
assert(!IsSpecImportFailed);
(void)IsSpecImportFailed;
Decls.push_back(ND);
}
SetExternalVisibleDeclsForName(DC, Name, Decls);
return true;
}
void ExternalASTMerger::FindExternalLexicalDecls(
const DeclContext *DC, llvm::function_ref<bool(Decl::Kind)> IsKindWeWant,
SmallVectorImpl<Decl *> &Result) {
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
ForEachMatchingDC(DC, [&](ASTImporter &Forward, ASTImporter &Reverse,
Source<const DeclContext *> SourceDC) -> bool {
for (const Decl *SourceDecl : SourceDC.get()->decls()) {
if (IsKindWeWant(SourceDecl->getKind())) {
auto ImportedDeclOrErr = Forward.Import(SourceDecl);
if (ImportedDeclOrErr)
assert(!(*ImportedDeclOrErr) ||
IsSameDC((*ImportedDeclOrErr)->getDeclContext(), DC));
else
llvm::consumeError(ImportedDeclOrErr.takeError());
Add support for remembering origins to ExternalASTMerger ExternalASTMerger has hitherto relied on being able to look up any Decl through its named DeclContext chain. This works for many cases, but causes problems for function-local structs, which cannot be looked up in their containing FunctionDecl. An example case is void f() { { struct S { int a; }; } { struct S { bool b; }; } } It is not possible to lookup either of the two Ses individually (or even to provide enough information to disambiguate) after parsing is over; and there is typically no need to, since they are invisible to the outside world. However, ExternalASTMerger needs to be able to complete either S on demand. This led to an XFAIL on test/Import/local-struct, which this patch removes. The way the patch works is: It defines a new data structure, ExternalASTMerger::OriginMap, which clients are expected to maintain (default-constructing if the origin does not have an ExternalASTMerger servicing it) As DeclContexts are imported, if they cannot be looked up by name they are placed in the OriginMap. This allows ExternalASTMerger to complete them later if necessary. As DeclContexts are imported from an origin that already has its own OriginMap, the origins are forwarded – but only for those DeclContexts that are actually used. This keeps the amount of stored data minimal. The patch also applies several improvements from review: - Thoroughly documents the interface to ExternalASTMerger; - Adds optional logging to help track what's going on; and - Cleans up a bunch of braces and dangling elses. Differential Revision: https://reviews.llvm.org/D38208 llvm-svn: 314336
2017-09-28 03:57:58 +08:00
}
}
return false;
});
}