| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 111101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 111087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
keeping track of unused file scoped variables.
This is only preparation, currently only static function definitions are tracked, as before.
llvm-svn: 111025
|
|
|
|
|
|
| |
will apply all fixes even when there were other errors in the file.
llvm-svn: 111020
|
|
|
|
|
|
| |
into a PCH/AST file.
llvm-svn: 111006
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 110996
|
|
|
|
|
|
| |
need to force it
llvm-svn: 110993
|
|
|
|
|
|
| |
chained PCH to overwrite declarations from earlier PCH files in dependent ones. Tell Sema to note when it changes AST nodes so that they have to be reserialized. Finally, the ObjCProtocolDecls created in forward decls, like the ObjCInterfaceDecls in @class forward decls, are not lexically part of the decl context; only the definition is.
llvm-svn: 110989
|
|
|
|
|
|
|
|
| |
a -cc1 option. The Darwin linker complains about mixed visibility when linking
gcc-built objects with clang-built objects, and the optimization isn't really
that valuable. Platforms with less ornery linkers can feel free to enable this.
llvm-svn: 110979
|
|
|
|
|
|
|
| |
for parsing, so that it can persist beyond the lifetime of the parsing
call.
llvm-svn: 110978
|
|
|
|
| |
llvm-svn: 110945
|
|
|
|
| |
llvm-svn: 110912
|
|
|
|
|
|
| |
ExecuteCompilerInvocation in libFrontend.
llvm-svn: 110903
|
|
|
|
|
|
| |
linker in use.
llvm-svn: 110871
|
|
|
|
|
|
|
|
| |
-There are 2 instances that change the TokenID for GNU libstdc++ 4.2 compatibility.
To handler those cases introduce a RevertedTokenID bitfield, RevertTokenIDToIdentifier() and hasRevertedTokenIDToIdentifier() methods.
Store the bitfield in PCH.
llvm-svn: 110868
|
|
|
|
| |
llvm-svn: 110860
|
|
|
|
|
|
| |
with the breakage.
llvm-svn: 110840
|
|
|
|
| |
llvm-svn: 110804
|
|
|
|
|
|
|
|
| |
and create separate decl nodes for forward declarations and the
definition," which appears to be causing significant Objective-C
breakage.
llvm-svn: 110803
|
|
|
|
| |
llvm-svn: 110666
|
|
|
|
| |
llvm-svn: 110663
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 110596
|
|
|
|
| |
llvm-svn: 110570
|
|
|
|
|
|
| |
Strictly speaking, implementations don't go in headers but there's no law against it.
llvm-svn: 110567
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 110566
|
|
|
|
|
|
| |
of just ignoring it.
llvm-svn: 110525
|
|
|
|
|
|
| |
#undefs in -dD mode. (PR7818)
llvm-svn: 110523
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
llvm-svn: 110507
|
|
|
|
|
|
|
|
|
| |
to a flag (-analyzer-check-idempotent-operations)
- Added IdempotentOperationChecker to experimental analyses for testing purposes
- Updated test cases to explictly call the checker
llvm-svn: 110482
|
|
|
|
| |
llvm-svn: 110432
|
|
|
|
| |
llvm-svn: 110414
|
|
|
|
| |
llvm-svn: 110378
|
|
|
|
| |
llvm-svn: 110357
|
|
|
|
|
|
|
|
| |
end of the translation unit that
included the PCH, as God intended.
llvm-svn: 110324
|
|
|
|
| |
llvm-svn: 110323
|
|
|
|
|
|
| |
loaded from PCH.
llvm-svn: 110322
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 110315
|
|
|
|
| |
llvm-svn: 110262
|
|
|
|
| |
llvm-svn: 110247
|
|
|
|
|
|
| |
about method pool hits for the moment.
llvm-svn: 110245
|
|
|
|
| |
llvm-svn: 110229
|
|
|
|
| |
llvm-svn: 110219
|
|
|
|
|
|
|
| |
file buffers until the code completion results are destroyed;
diagnostics may end up referring into the source.
llvm-svn: 110216
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|