Commit Graph

59 Commits

Author SHA1 Message Date
Sean Callanan 17c8c20d7e 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
2017-07-10 23:47:00 +00:00
Lang Hames 86ac9182e0 Add testcase for r305850.
Accidentally left this out of the original commit.

llvm-svn: 307444
2017-07-07 21:51:11 +00:00
Lang Hames 8ca265f4a1 Call setMustBuildLookupTable on TagDecls in ExternalASTMerger
Summary:
setMustBuildLookupTable should be called on imported TagDecls otherwise we may fail
to import their member decls (if they have any).

Not calling the setMustBuildLookupTable method results in a failure in the attached test
case when lookup for the 'x' member fails on struct S, which hasn't had its decls imported
elsewhere. (By contrast the member-in-struct testcase hasn't run into this issue
because the import of its decls is triggered when the struct instance is defined, and the
member access follows this).

Reviewers: spyffe, rsmith

Reviewed By: spyffe, rsmith

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

llvm-svn: 305619
2017-06-17 00:12:38 +00:00
Sean Callanan 9092d4795d [ASTImporter] Improve handling of incomplete types
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.

llvm-svn: 302975
2017-05-13 00:46:33 +00:00
Sean Callanan 84dfb56926 Added an Importer test for in-class member initializers.
llvm-svn: 301573
2017-04-27 18:10:29 +00:00
Sean Callanan b7160ca466 [clang-import-test] Lookup inside contexts
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

llvm-svn: 299976
2017-04-11 19:33:35 +00:00
Sean Callanan 7d982509b8 Testbed and skeleton of a new expression parser
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

llvm-svn: 290367
2016-12-22 20:03:14 +00:00
Sean Callanan ca2f40dd68 Reverting r290004, r290006, r290010 pending review.
llvm-svn: 290130
2016-12-19 19:15:43 +00:00
Sean Callanan fe929aa33c Testbed and skeleton of a new expression parser
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

llvm-svn: 290004
2016-12-16 23:21:38 +00:00