| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
clang_codeCompleteAt(). This uncovered a few issues with the latter:
- ASTUnit wasn't saving/restoring diagnostic state appropriately between
reparses and code completions.
- "Overload" completions weren't being passed through to the client
llvm-svn: 116241
|
|
|
|
|
|
|
|
|
| |
improvements to the compiler and the introduction of crash recovery,
it no longer makes sense to allow this mode. Moreover, this eliminates
one use of the "clang" executable from within libclang; we'd like them
all to go away.
llvm-svn: 116207
|
|
|
|
|
|
| |
rather than a space.
llvm-svn: 116097
|
|
|
|
|
|
|
|
| |
produces a simple "display" name that captures the
arguments/parameters for a function, function template, class
template, or class template specialization.
llvm-svn: 115428
|
|
|
|
|
|
|
| |
member function or an Objective-C method, which other member
functions/methods it overrides.
llvm-svn: 115338
|
|
|
|
| |
llvm-svn: 115224
|
|
|
|
|
|
|
| |
ensure we at least get some minimal testing of running in a multithreaded
environment (for example, having a reduced stack size).
llvm-svn: 115200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
I will not mix declaration and statements in C90.
llvm-svn: 113821
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead"
This reverts commit r113631
Conflicts:
CMakeLists.txt
lib/CodeGen/CMakeLists.txt
llvm-svn: 113817
|
|
|
|
|
|
|
|
|
| |
to an "overloaded" set of declarations. This cursor kind works for
unresolved references to functions/templates (e.g., a call within a
template), using declarations, and Objective-C class and protocol
forward declarations.
llvm-svn: 113805
|
|
|
|
|
|
| |
of whatever we were using before...
llvm-svn: 113631
|
|
|
|
| |
llvm-svn: 113489
|
|
|
|
|
|
|
|
|
| |
clang_getSpecializedCursorTemplate(), which determines the template
(or member thereof) that the given cursor specializes or from which it
was instantiated. This routine can be used to establish a link between
templates and their instantiations/specializations.
llvm-svn: 112780
|
|
|
|
|
|
|
|
| |
adding the API hooks clang_isVirtualBase() and clang_getCXXAccessSpecifier() to query properties of the base specifier.
Implements <rdar://problem/8274883>.
llvm-svn: 112296
|
|
|
|
|
|
|
|
|
|
|
| |
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
3rd try. How embarrassing.
llvm-svn: 112180
|
|
|
|
|
|
| |
path and ...", it is failing tests.
llvm-svn: 112161
|
|
|
|
|
|
|
|
|
| |
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
Provide a libclang function that sorts the results.
llvm-svn: 112149
|
|
|
|
|
|
| |
collection type for iboutletcollection attributes.
llvm-svn: 112139
|
|
|
|
|
|
|
| |
into the clients", because the C standard library sucks. Where's my
stable sort, huh?
llvm-svn: 112121
|
|
|
|
|
|
|
| |
into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.
llvm-svn: 112095
|
|
|
|
|
|
|
| |
of a cursor or code-completion result, e.g., whether that result
refers to an unavailable, deleted, or deprecated declaration.
llvm-svn: 111858
|
|
|
|
|
|
|
|
|
| |
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
llvm-svn: 111667
|
|
|
|
| |
llvm-svn: 111580
|
|
|
|
|
|
|
| |
completion step with -code-completion-at=, to allow testing simulated source
changes.
llvm-svn: 111579
|
|
|
|
| |
llvm-svn: 111559
|
|
|
|
|
|
| |
reparse, to allow testing distinct inputs.
llvm-svn: 111448
|
|
|
|
| |
llvm-svn: 111279
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
"editing" mode, introduce a separate function
clang_defaultEditingTranslationUnitOptions() that retrieves the set of
options. No functionality change.
llvm-svn: 110613
|
|
|
|
| |
llvm-svn: 110602
|
|
|
|
| |
llvm-svn: 110596
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
<rdar://problem/8250669>.
llvm-svn: 109822
|
|
|
|
| |
llvm-svn: 109447
|
|
|
|
|
|
|
|
| |
interaction, by effectively defaulting to
DISABLE_SMART_POINTERS. We're embracing the model where all AST nodes
are ASTContext-allocated and live as long as the ASTContext lives.
llvm-svn: 109374
|
|
|
|
|
|
|
| |
ASTUnit/CXTranslationUnit. We can't actually use this preamble yet,
however.
llvm-svn: 109202
|
|
|
|
|
|
| |
to try to keep as much logical grouping as possible.
llvm-svn: 109085
|
|
|
|
| |
llvm-svn: 108838
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
test the performance of code-completion without testing the
performance of printf().
llvm-svn: 108172
|
|
|
|
| |
llvm-svn: 106531
|
|
|
|
|
|
|
|
| |
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: 105640
|
|
|
|
|
|
| |
scattered throughout the project Makefiles.
llvm-svn: 105638
|
|
|
|
|
|
| |
- This eliminates most dependencies on how Clang is installed relative to LLVM.
llvm-svn: 105637
|