Create a new Serialization module that contains all the PCH code, and will contain all the module code in the future. Update the Makefiles, CMake projects and the Xcode project. I hope I did everythi

Create a new Serialization module that contains all the PCH code, and will contain all the module code in the future. Update the Makefiles, CMake projects and the Xcode project. I hope I did everything right for Xcode. No functionality change.

llvm-svn: 111258

show more ...

When the # of top-level declarations changes after reparsing a
translation unit, refresh code-completion results because they've
probably changed. However, enforce a cooldown period between
refreshes

When the # of top-level declarations changes after reparsing a
translation unit, refresh code-completion results because they've
probably changed. However, enforce a cooldown period between
refreshes, to avoid thrashing.

llvm-svn: 111218

show more ...

Move include to the proper place. No functionality change

llvm-svn: 111204

Implement support for cached code completions for
nested-name-specifiers. Also includes fixes to the generation of
nested-name-specifier result in the non-cached case; we were producing
lame results

Implement support for cached code completions for
nested-name-specifiers. Also includes fixes to the generation of
nested-name-specifier result in the non-cached case; we were producing
lame results for namespaces and namespace aliases, which (1) didn't
always have nested-name-specifiers when we want them, and (2) did not
have the necessary "::" as part of the completion.

llvm-svn: 111203

show more ...

Formatting fixes. No functionality change

llvm-svn: 111186

Implement name hiding of cached global code-completion results.

llvm-svn: 111184

Move some code out-of-line which has long since grown too large to be
inlined. No functionality change.

llvm-svn: 111176

When caching code completions for global declarations, keep track of
the usage type of each declaration result, then compare those types to
the preferred type of the completion. This provides parity

When caching code completions for global declarations, keep track of
the usage type of each declaration result, then compare those types to
the preferred type of the completion. This provides parity in the
priority calculation between the code-completion results produced
directly from Sema and those cached by ASTUnit.

For the standard Cocoa.h (+ others) example, there's a penalty of 3-4
hundredeths of a second when caching the global results (for ~31,000
results), because we need an ASTContext-agnostic representation of
types for the comparison, and therefore we use... strings. Eventually,
we'd like to implement a more efficient ASTContext-agnostic encoding
of types.

llvm-svn: 111165

show more ...

Dereferencing NULL pointers is such poor form.

llvm-svn: 111150

When caching global completion results, keep track of the simplified
type class, so that we can adjust priorities appropriately when the
preferred type for the context and the actual type of the comp

When caching global completion results, keep track of the simplified
type class, so that we can adjust priorities appropriately when the
preferred type for the context and the actual type of the completion
are similar.

This gets us one step closer to parity of the cached completion
results with the non-cached completion results.

llvm-svn: 111139

show more ...

Open AST/PCH files in binary mode.

llvm-svn: 111106

Extend the code-completion caching infrastructure to include global
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit comple

Extend the code-completion caching infrastructure to include global
declarations (in addition to macros). Each kind of declaration maps to
a certain set of completion contexts, and the ASTUnit completion logic
introduces the completion strings for those declarations if the actual
code-completion occurs in one of the contexts where it matters.

There are a few new code-completion-context kinds. Without these,
certain completions (e.g., after "using namespace") would need to
suppress all global completions, which would be unfortunate.

Note that we don't get the priorities right for global completions,
because we don't have enough type information. We'll need a way to
compare types in an ASTContext-agnostic way before this can be
implemented.

llvm-svn: 111093

show more ...

Implement caching of code-completion results for macro definitions
when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-comp

Implement caching of code-completion results for macro definitions
when the CXTranslationUnit_CacheCompletionResults option is given to
clang_parseTranslationUnit(). Essentially, we compute code-completion
results for macro definitions after we have parsed the file, then
store an ASTContext-agnostic version of those results (completion
string, cursor kind, priority, and active contexts) in the
ASTUnit. When performing code completion in that ASTUnit, we splice
the macro definition results into the results provided by the actual
code-completion (which has had macros turned off) before libclang gets
those results. We use completion context information to only splice in
those results that make sense for that context.

With a completion involving all of the macros from Cocoa.h and a few other
system libraries (totally ~8500 macro definitions) living in a
precompiled header, we get about a 9% performance improvement from
code completion, since we no longer have to deserialize all of the
macro definitions from the precompiled header.

Note that macro definitions are merely the canary; the cache is
designed to also support other top-level declarations, which should be
a bigger performance win. That optimization will be next.

Note also that there is no mechanism for determining when to throw
away the cache and recompute its contents.

llvm-svn: 111051

show more ...

Implement clang_saveTranslationUnit(), which saves a translation unit
into a PCH/AST file.

llvm-svn: 111006

Teach ASTUnit to hold on to the Sema object and ASTConsumer that are
used when parsing (or re-parsing) a file. Also, when loading a
precompiled header into ASTUnit, create a Sema object that holds on

Teach ASTUnit to hold on to the Sema object and ASTConsumer that are
used when parsing (or re-parsing) a file. Also, when loading a
precompiled header into ASTUnit, create a Sema object that holds onto
semantic-analysis information.

llvm-svn: 111003

show more ...

Reintroduce the ASTConsumer/ASTUnit fix from r110610, it has nothing to do with the breakage.

llvm-svn: 110840

Fix a thinko in the creation of temporary files for the precompiled preamble

llvm-svn: 110804

Speculatively revert r110610 " Make ObjCInterfaceDecl redeclarable,
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
br

Speculatively revert r110610 " Make ObjCInterfaceDecl redeclarable,
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.

llvm-svn: 110803

show more ...

- Make ObjCInterfaceDecl redeclarable, and create separate decl nodes for forward declarations and the definition.
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead t

- Make ObjCInterfaceDecl redeclarable, and create separate decl nodes for forward declarations and the definition.
- Eagerly create ObjCInterfaceTypes for declarations.
- The two above changes lead to a 0.5% increase in memory use and no speed regression when parsing Cocoa.h. On the other hand, now chained PCH works when there's a forward declaration in one PCH and the interface definition in another.
- Add HandleInterestingDecl to ASTConsumer. PCHReader passes the "interesting" decls it finds to this function instead of HandleTopLevelDecl. The default implementation forwards to HandleTopLevelDecl, but ASTUnit's handler for example ignores them. This fixes a potential crash when lazy loading of PCH data would cause ASTUnit's "top level" declaration collection to change while being iterated.

llvm-svn: 110610

show more ...

Use precompiled preambles for in-process code completion.

llvm-svn: 110596

Add an environment variable that makes libclang use chaining for PCH.

llvm-svn: 110414

Give clang_codeCompleteAt() an "options" parameter, and add a new
flags enumeration + default-generating function that allows
code-completion to be customized via the libclang API.

Plus, turn on spe

Give clang_codeCompleteAt() an "options" parameter, and add a new
flags enumeration + default-generating function that allows
code-completion to be customized via the libclang API.

Plus, turn on spell-checking when performing code completion.

llvm-svn: 110319

show more ...

When performing in-process code completion, don't free the remapped
file buffers until the code completion results are destroyed;
diagnostics may end up referring into the source.

llvm-svn: 110216

Add code-completion support directly to ASTUnit, which performs code
completion within the translation unit using the same command-line
arguments for parsing the translation unit. Eventually, we'll r

Add code-completion support directly to ASTUnit, which performs code
completion within the translation unit using the same command-line
arguments for parsing the translation unit. Eventually, we'll reuse
the precompiled preamble to improve code-completion performance, and
this also gives us a place to cache results.

Expose this function via the new libclang function
clang_codeCompleteAt(), which performs the code completion within a
CXTranslationUnit. The completion occurs in-process
(clang_codeCompletion() runs code completion out-of-process).

llvm-svn: 110210

show more ...

When we try (but fail) to build a precompiled preamble, wait for a
short "cooling off" period (defaulting to 5 reparses) before trying to
build a precompiled preamble again. Previously, if we failed

When we try (but fail) to build a precompiled preamble, wait for a
short "cooling off" period (defaulting to 5 reparses) before trying to
build a precompiled preamble again. Previously, if we failed to build
the precompiled preamble at any time, we just gave up the whole
charade any never tried again.

llvm-svn: 110187

show more ...