History log of /llvm-project/clang/lib/AST/ExternalASTMerger.cpp (Results 1 – 25 of 33)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: llvmorg-21-init
# 263fed7c 17-Jan-2025 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152)

Part for relanding https://github.com/llvm/llvm-project/pull/122887.

I split this to test where the pe

[AST] Add OriginalDC argument to ExternalASTSource::FindExternalVisibleDeclsByName (#123152)

Part for relanding https://github.com/llvm/llvm-project/pull/122887.

I split this to test where the performance regession comes from if
modules are not used.

show more ...


# 731db2a0 16-Jan-2025 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

Revert "[C++20] [Modules] Support module level lookup (#122887)"

This reverts commit 7201cae106260aeb3e9bbbb7d5291ff30f05076a.


# 7201cae1 15-Jan-2025 Chuanqi Xu <yedeng.yd@linux.alibaba.com>

[C++20] [Modules] Support module level lookup (#122887)

Close https://github.com/llvm/llvm-project/issues/90154

This patch is also an optimization to the lookup process to utilize the
informatio

[C++20] [Modules] Support module level lookup (#122887)

Close https://github.com/llvm/llvm-project/issues/90154

This patch is also an optimization to the lookup process to utilize the
information provided by `export` keyword.

Previously, in the lookup process, the `export` keyword only takes part
in the check part, it doesn't get involved in the lookup process. That
said, previously, in a name lookup for 'name', we would load all of
declarations with the name 'name' and check if these declarations are
valid or not. It works well. But it is inefficient since it may load
declarations that may not be wanted.

Note that this patch actually did a trick in the lookup process instead
of bring module information to DeclarationName or considering module
information when deciding if two declarations are the same. So it may
not be a surprise to me if there are missing cases. But it is not a
regression. It should be already the case. Issue reports are welcomed.

In this patch, I tried to split the big lookup table into a lookup table
as before and a module local lookup table, which takes a combination of
the ID of the DeclContext and hash value of the primary module name as
the key. And refactored `DeclContext::lookup()` method to take the
module information. So that a lookup in a DeclContext won't load
declarations that are local to **other** modules.

And also I think it is already beneficial to split the big lookup table
since it may reduce the conflicts during lookups in the hash table.

BTW, this patch introduced a **regression** for a reachability rule in
C++20 but it was false-negative. See
'clang/test/CXX/module/module.interface/p7.cpp' for details.

This patch is not expected to introduce any other
regressions for non-c++20-modules users since the module local lookup
table should be empty for them.

---

On the API side, this patch unfortunately add a maybe-confusing argument
`Module *NamedModule` to
`ExternalASTSource::FindExternalVisibleDeclsByName()`. People may think
we can get the information from the first argument `const DeclContext
*DC`. But sadly there are declarations (e.g., namespace) can appear in
multiple different modules as a single declaration. So we have to add
additional information to indicate this.

show more ...


# 466753b1 14-Jan-2025 Kazu Hirata <kazu@google.com>

[AST] Avoid repeated map lookups (NFC) (#122858)


Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6
# 8dc76478 03-Jun-2023 Kazu Hirata <kazu@google.com>

[AST] Use DenseMapBase::lookup (NFC)


Revision tags: llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1
# d245f2e8 17-Oct-2021 Kazu Hirata <kazu@google.com>

[clang] Use llvm::erase_if (NFC)


Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4
# 0cb7e7ca 17-Mar-2021 Vassil Vassilev <v.g.vassilev@gmail.com>

Make iteration over the DeclContext::lookup_result safe.

The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```

is not safe when in the loop body we tr

Make iteration over the DeclContext::lookup_result safe.

The idiom:
```
DeclContext::lookup_result R = DeclContext::lookup(Name);
for (auto *D : R) {...}
```

is not safe when in the loop body we trigger deserialization from an AST file.
The deserialization can insert new declarations in the StoredDeclsList whose
underlying type is a vector. When the vector decides to reallocate its storage
the pointer we hold becomes invalid.

This patch replaces a SmallVector with an singly-linked list. The current
approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers.
The linked list is 3, 5, or 7. We do better in terms of memory usage for small
cases (and worse in terms of locality -- the linked list entries won't be near
each other, but will be near their corresponding declarations, and we were going
to fetch those memory pages anyway). For larger cases: the vector uses a
doubling strategy for reallocation, so will generally be between half-full and
full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth
of space allocated currently and will be 2N pointers with the linked list. So we
break even when there are N=6 entries and slightly lose in terms of memory usage
after that. We suspect that's still a win on average.

Thanks to @rsmith!

Differential revision: https://reviews.llvm.org/D91524

show more ...


Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1
# 7e6294c0 14-Nov-2019 Raphael Isemann <teemperor@gmail.com>

Modernize llvm::Error handling in ExternalASTMerger


# 51e0bbb0 04-Oct-2019 Raphael Isemann <teemperor@gmail.com>

[lldb][modern-type-lookup] No longer import temporary declarations into the persistent AST

Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were original

[lldb][modern-type-lookup] No longer import temporary declarations into the persistent AST

Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext
causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that
can complete them.

I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable
as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future,
I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this
is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803.

What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the
declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger
is already connected with ASTImporters to these different sources, so this patch is essentially just two parts:
1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST.
2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we
can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually
come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST.

The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch.

This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests
which need special treatment).

Reviewers: shafik, martong

Reviewed By: martong

Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68326

llvm-svn: 373711

show more ...


# cf628714 01-Oct-2019 Raphael Isemann <teemperor@gmail.com>

[clang][lldb][NFC] Encapsulate ExternalASTMerger::ImporterSource

NFC preparation work for upcoming ExternalASTMerger patches.

llvm-svn: 373312


# e7714fe7 30-Sep-2019 Raphael Isemann <teemperor@gmail.com>

[lldb][clang][modern-type-lookup] Use ASTImporterSharedState in ExternalASTMerger

Summary:
The ExternalASTMerger should use the ASTImporterSharedState. This allows it to
handle std::pair in LLDB (bu

[lldb][clang][modern-type-lookup] Use ASTImporterSharedState in ExternalASTMerger

Summary:
The ExternalASTMerger should use the ASTImporterSharedState. This allows it to
handle std::pair in LLDB (but the rest of libc++ is still work in progress).

Reviewers: martong, shafik, a.sidorin

Subscribers: rnkovacs, christof, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68140

llvm-svn: 373193

show more ...


Revision tags: llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3
# 2b3d49b6 14-Aug-2019 Jonas Devlieghere <jonas@devlieghere.com>

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
o

[Clang] Migrate llvm::make_unique to std::make_unique

Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.

Differential revision: https://reviews.llvm.org/D66259

llvm-svn: 368942

show more ...


Revision tags: llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1
# 5ac6d490 15-May-2019 Gabor Marton <martongabesz@gmail.com>

[ASTImporter] Use llvm::Expected and Error in the importer API

Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves

[ASTImporter] Use llvm::Expected and Error in the importer API

Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves the following:
- remove old Import functions which returned with a pointer,
- use the Import_New functions (which return with Err or Expected) everywhere
and handle their return value
- rename Import_New functions to Import
This affects both Clang and LLDB.

Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin

Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits

Tags: #clang, #lldb

Differential Revision: https://reviews.llvm.org/D61438

llvm-svn: 360760

show more ...


# a1f6b103 08-Apr-2019 Balazs Keri <1.int32@gmail.com>

Changed every use of ASTImporter::Import to Import_New

Reviewers: a.sidorin, shafik, martong, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, martong, Szelethus, gamesh411, cfe-com

Changed every use of ASTImporter::Import to Import_New

Reviewers: a.sidorin, shafik, martong, a_sidorin

Reviewed By: a_sidorin

Subscribers: rnkovacs, dkrupp, martong, Szelethus, gamesh411, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D55049

llvm-svn: 357913

show more ...


# 5e3a7698 20-Mar-2019 Raphael Isemann <teemperor@gmail.com>

Remove the unused return value in ASTImporter::Imported [NFC]

Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor i

Remove the unused return value in ASTImporter::Imported [NFC]

Summary:
`ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else)
nor is it documented.

Reviewers: balazske, martong, a.sidorin, shafik

Reviewed By: balazske, martong

Subscribers: rnkovacs, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D59595

llvm-svn: 356592

show more ...


Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1
# 2946cd70 19-Jan-2019 Chandler Carruth <chandlerc@gmail.com>

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 ne

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

show more ...


Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3
# ddedf0f9 29-Nov-2018 Raphael Isemann <teemperor@gmail.com>

Set MustBuildLookupTable on PrimaryContext in ExternalASTMerger

Summary:
`MustBuildLookupTable` must always be called on a primary context as we otherwise
trigger an assert, but we don't ensure that

Set MustBuildLookupTable on PrimaryContext in ExternalASTMerger

Summary:
`MustBuildLookupTable` must always be called on a primary context as we otherwise
trigger an assert, but we don't ensure that this will always happen in our code right now.

This patch explicitly requests the primary context when doing this call as this shouldn't break
anything (as calling `getPrimaryContext` on a context which is its own primary context is a no-op)
but will catch these rare cases where we somehow operate on a declaration context that is
not its own primary context.

See also D54863.

Reviewers: martong, a.sidorin, shafik

Reviewed By: martong

Subscribers: davide, rnkovacs, cfe-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D54898

llvm-svn: 347863

show more ...


Revision tags: llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1
# 3b30d658 19-Oct-2018 Balazs Keri <1.int32@gmail.com>

[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

[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

show more ...


Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1
# 26f72a96 12-Jul-2018 Gabor Marton <martongabesz@gmail.com>

[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 im

[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

show more ...


Revision tags: llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2
# fdc3207d 26-Jan-2018 Sam McCall <sam.mccall@gmail.com>

[ASTImporter] avoid warnings: unused var, switch covered

llvm-svn: 323524


# 8fc8510c 26-Jan-2018 Aleksei Sidorin <a.sidorin@samsung.com>

[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

[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

show more ...


Revision tags: llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1
# 6fc579df 28-Sep-2017 Nico Weber <nicolasweber@gmx.de>

Fix -Wcast-qual warning after r314336.

llvm-svn: 314424


# 967d4384 27-Sep-2017 Sean Callanan <scallanan@apple.com>

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

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

show more ...


Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1
# 1eac879d 25-Jul-2017 Sean Callanan <scallanan@apple.com>

[ExternalASTMerger] Import Objective-C classes

This patch adds functionality and a test for importing Objective-C classes
and their methods.

It also adds a flag to clang-import-test to set the lang

[ExternalASTMerger] Import Objective-C classes

This patch adds functionality and a test for importing Objective-C classes
and their methods.

It also adds a flag to clang-import-test to set the language used for
parsing. This takes the same argument format as the -x option to the
driver.

Differential Revision: https://reviews.llvm.org/D35274

llvm-svn: 309014

show more ...


# 17c8c20d 10-Jul-2017 Sean Callanan <scallanan@apple.com>

clang-import-test had some dead code. I did the following to eliminate it:

- eliminated error handling for the indirect CompilerInstance, which should
never generate an error as it is created;
-

clang-import-test had some dead code. I did the following to eliminate it:

- eliminated error handling for the indirect CompilerInstance, which should
never generate an error as it is created;
- added a new test for direct importation; and
- removed an unused implementation of the CompleteType() API.

This brings clang-import-test.cpp and ExternalASTMerge.cpp back to 100%
coverage on all metrics measured by DLLVM_BUILD_INSTRUMENTED_COVERAGE.

Differential Revision: https://reviews.llvm.org/D35220

llvm-svn: 307600

show more ...


12