| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
is used for annotating macro arguments. This finishes up <rdar://problem/8044584>.
llvm-svn: 111066
|
|
|
|
|
|
| |
arguments of a macro instantiation using the closest cursor with the same spelling location. Because macro arguments can get token pasted in any arbitrary order, we use the annotation map to paper over the token -> cursor annotations during our post-processing stage. This fixes most of <rdar://problem/8044584>, but still doesn't work for assert().
llvm-svn: 111062
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
later
llvm-svn: 111016
|
|
|
|
|
|
| |
into a PCH/AST file.
llvm-svn: 111006
|
|
|
|
|
|
|
| |
the code-completion consumer. The consumer can use this information to
augument, filter, or display the code-completion results.
llvm-svn: 110858
|
|
|
|
|
|
|
|
|
|
| |
clang_reparseTranslationUnit(), along with a function to retrieve the
default recommended reparsing options for a translation unit.
Also, add the CXTranslationUnit_CacheCompletionResults flag, which is
also currently unused.
llvm-svn: 110811
|
|
|
|
|
|
|
|
| |
provided by __builtin_types_compatible_p and __builtin_va_arg
expressions, now that Abramo has added proper type-source information
to those expressions.
llvm-svn: 110681
|
|
|
|
|
|
|
|
| |
"editing" mode, introduce a separate function
clang_defaultEditingTranslationUnitOptions() that retrieves the set of
options. No functionality change.
llvm-svn: 110613
|
|
|
|
| |
llvm-svn: 110599
|
|
|
|
| |
llvm-svn: 110596
|
|
|
|
| |
llvm-svn: 110438
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
declarations that we saw when creating the precompiled preamble, and
provide those declarations in addition to the declarations parsed in
the main source file when traversing top-level declarations. This
makes the use of precompiled preambles a pure optimization, rather
than changing the semantics of the parsed translation unit.
llvm-svn: 110131
|
|
|
|
| |
llvm-svn: 110062
|
|
|
|
|
|
| |
anything.
llvm-svn: 109958
|
|
|
|
|
|
| |
<rdar://problem/8250669>.
llvm-svn: 109822
|
|
|
|
|
|
| |
possible assertion failure in SourceManager in the call to Lexer::GetBeginningOfToken(). Fixes <rdar://problem/8244873>.
llvm-svn: 109713
|
|
|
|
|
|
|
| |
libclang, so that clang_annotateTokens() doesn't get confused and miss
annotations.
llvm-svn: 109706
|
|
|
|
| |
llvm-svn: 109550
|
|
|
|
|
|
|
|
|
|
|
|
| |
CodeGenModule::MayDeferGeneration into a new function,
DeclIsRequiredFunctionOrFileScopedVar.
This function is part of the public CodeGen interface since it's essentially a CodeGen predicate that is also
needed by the PCH mechanism to determine whether a decl needs to be deserialized during PCH loading for codegen purposes.
This fixes current (and avoids future) codegen-from-PCH bugs.
llvm-svn: 109546
|
|
|
|
|
|
| |
code-completion command lines to stderr
llvm-svn: 109395
|
|
|
|
|
|
|
| |
ASTUnit/CXTranslationUnit. We can't actually use this preamble yet,
however.
llvm-svn: 109202
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is present.
Rather than using clang_getCursorExtent(), which requires
us to lex the token at the ending position to determine its
length. Then, we'd be comparing [a, b) source ranges that cover the
characters in the range rather than the normal behavior for Clang's
source ranges, which covers the tokens in the range. However, relexing
causes us to read the source file (which may come from a precompiled
header), which is rather unfortunate and affects performance.
In the new scheme, we only use Clang-style source ranges that cover
the tokens in the range. At the entry points where this matters
(clang_annotateTokens, clang_getCursor), we make sure to move source
locations to the start of the token.
Addresses most of <rdar://problem/8049381>.
llvm-svn: 109134
|
|
|
|
|
|
| |
block is invalid' by checking that the body of a BlockDecl is null before constructing a CXCursor.
llvm-svn: 109097
|
|
|
|
|
|
| |
anonymous symbols. Fixes <rdar://problem/8221557>.
llvm-svn: 109095
|
|
|
|
|
|
|
|
|
| |
will eventually replace
clang_createTranslationUnitFromSourceFile(). The only addition in
clang_parseTranslationUnit() is a set of flags that can control how
the translation unit is loaded. More interesting flags will be coming.
llvm-svn: 109027
|
|
|
|
|
|
|
|
| |
reparses an already-parsed translation unit. At the moment it's just a
convenience function, but we hope to use it for performance
optimizations.
llvm-svn: 108756
|
|
|
|
| |
llvm-svn: 108067
|
|
|
|
| |
llvm-svn: 107998
|
|
|
|
|
|
|
| |
spell-checking. By default, spell-checking is enabled for Clang
(obviously) but disabled in CIndex for performance reasons.
llvm-svn: 107992
|
|
|
|
|
|
| |
suppressing copies of objects with trivial copy constructors.
llvm-svn: 107857
|
|
|
|
|
|
| |
breaking bootstrap on Linux.
llvm-svn: 107837
|
|
|
|
|
|
| |
newly-narrowed scope. No functionality change.
llvm-svn: 107828
|
|
|
|
|
|
|
| |
pass -ccc-clang-cxx to force C++ support (even if the binary was built without
it).
llvm-svn: 107324
|
|
|
|
|
|
|
| |
cxloc::translateSourceLocation() (thus causing all clients of this
function to have the same behavior).
llvm-svn: 107101
|
|
|
|
|
|
|
|
| |
This is done by
adding a clang_getCursorResultType() function (which complements clang_getResultType()).
llvm-svn: 106473
|
|
|
|
|
|
|
|
| |
includes adding a new
function, clang_getResultType(), which returns the result type of the function type.
llvm-svn: 106459
|
|
|
|
| |
llvm-svn: 106451
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to use them instead of SourceRange. CharSourceRange is just a SourceRange
plus a bool that indicates whether the range has the end character resolved
or whether the end location is the start of the end token. While most of
the compiler wants to think of ranges that have ends that are the start of
the end token, the printf diagnostic stuff wants to highlight ranges within
tokens.
This is transparent to the diagnostic stuff. To start taking advantage of
the new capabilities, you can do something like this:
Diag(..) << CharSourceRange::getCharRange(Begin,End)
llvm-svn: 106338
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, there are two effective changes:
- Attr::Kind has been changed to attr::Kind, in a separate namespace
rather than the Attr class. This is because the enumerator needs to
be visible to parse.
- The class definitions for the C++0x attributes other than aligned are
generated by TableGen.
The specific classes generated by TableGen are controlled by an array in
TableGen (see the accompanying commit to the LLVM repository). I will be
expanding the amount of code generated as I develop the new attributes system
while initially keeping it confined to these attributes.
llvm-svn: 106172
|
|
|
|
| |
llvm-svn: 105901
|
|
|
|
| |
llvm-svn: 105640
|
|
|
|
|
|
| |
scattered throughout the project Makefiles.
llvm-svn: 105638
|
|
|
|
|
|
| |
- This eliminates most dependencies on how Clang is installed relative to LLVM.
llvm-svn: 105637
|
|
|
|
|
|
|
| |
Clang can load it as a plugin. Original fix by Troy D. Straszheim,
which I extended with Darwin support. Fixes PR6801.
llvm-svn: 105630
|
|
|
|
| |
llvm-svn: 105525
|