I didn't commit clang-import-test.cpp in r307600, but it had some
changes that were part of https://reviews.llvm.org/D35220

Corrected that now.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@307602 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The ASTImporter should import CXX method overrides from the source context
when it imports a method decl.

Reviewers: spyffe, rsmith, doug.gregor

Reviewed By: spyffe

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@305850 91177308-0d34-0410-b5e6-96231b3b80d8

ASTImporter has some bugs when it's importing types 
that themselves come from an ExternalASTSource. This 
is exposed particularly in the behavior when 
comparing complete TagDecls with forward 
declarations. This patch does several things:

- Adds a test case making sure that conflicting 
  forward-declarations are resolved correctly;
- Extends the clang-import-test harness to test 
  two-level importing, so that we make sure we 
  complete types when necessary; and
- Fixes a few bugs I found this way. Failure to 
  complete types was one; however, I also discovered 
  that complete RecordDecls aren't properly added to 
  the redecls chain for existing forward 
  declarations.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@302975 91177308-0d34-0410-b5e6-96231b3b80d8

clang-import-test has until now been only able to report top-level Decls.
This is clearly insufficient; we should be able to look inside structs 
and namespaces also.  This patch adds new test cases for a variety of 
lookups inside existing ASTContexts, and adds the functionality necessar
to make most of these testcases work.  (One testcase is known to fail 
because of ASTImporter limitations when importing templates; I'll look 
into that separately.)

This patch also separates the core functionality out into 
ExternalASTMerger, an interface that allows clients like LLDB to make 
use of it.  clang-import-test now only has the machinery necessary to
set up the tests.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@299976 91177308-0d34-0410-b5e6-96231b3b80d8

Aleksey Shlypanikov pointed out my mistake in migrating an explicit
unique_ptr to auto - I was expecting the function returned a unique_ptr,
but instead it returned a raw pointer - introducing a leak.

Thanks Aleksey!

This reapplies r291184, reverted in r291249.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291270 91177308-0d34-0410-b5e6-96231b3b80d8

Caused a memory leak reported by asan. Reverting while I investigate.

This reverts commit r291184.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291249 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@291184 91177308-0d34-0410-b5e6-96231b3b80d8

Recommitted after formal approval.

LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project.

Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault.

Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code.

I propose that the parts required to build a simple expression parser be added to Clang. Initially, I aim to have the following features:

A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests.
A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside.
This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter. When complete, this tester will implement the first of the above goals.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290367 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290130 91177308-0d34-0410-b5e6-96231b3b80d8

This is part of the effort to get the i686-mingw32-RA-on-linux bot to like clang-import-test.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290010 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290006 91177308-0d34-0410-b5e6-96231b3b80d8

LLVM's JIT is now the foundation of dynamic-compilation features for many languages. Clang also has low-level support for dynamic compilation (ASTImporter and ExternalASTSource, notably). How the compiler is set up for dynamic parsing is generally left up to individual clients, for example LLDB's C/C++/Objective-C expression parser and the ROOT project.

Although this arrangement offers external clients the flexibility to implement dynamic features as they see fit, the lack of an in-tree client means that subtle bugs can be introduced that cause regressions in the external clients but aren't caught by tests (or users) until much later. LLDB for example regularly encounters complicated ODR violation scenarios where it is not immediately clear who is at fault.

Other external clients (notably, Cling) rely on similar functionality, and another goal is to break this functionality up into composable parts so that any client can be built easily on top of Clang without requiring extensive additional code.

I propose that the parts required to build a simple expression parser be added to Clang.  Initially, I aim to have the following features:

- A piece that looks up external declarations from a variety of sources (e.g., from previous dynamic compilations, from modules, or from DWARF) and uses clear conflict resolution rules to reconcile differences, with easily understood errors. This functionality will be supported by in-tree tests.

- A piece that works hand in hand with the LLVM JIT to resolve the locations of external declarations so that e.g. variables can be redeclared and (for high-performance applications like DTrace) external variables can be accessed directly from the registers where they reside.

This commit adds a tester that parses a sequence of source files and then uses them as source data for an expression. External references are resolved using an ExternalASTSource that responds to name queries using an ASTImporter. This is the setup that LLDB uses, and the motivating reason for MinimalImport in ASTImporter.  When complete, this tester will implement the first of the above goals.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@290004 91177308-0d34-0410-b5e6-96231b3b80d8