This is switches all the interfaces points (and most of the commenst
/ local variables I saw on my way through) regarding the
NestedMacroInstantiations bit.
The libclang enums corresponding to this state were renamed, but
a legacy enum was added with the old name, and the same value to keep
existing clients working. I've added a documentation blurb for it, but
let me know if there is a canonical way to document legacy elemenst of
the libclang interface.
No functionality changed here, even in tests.
llvm-svn: 135141
clang_codeCompleteGetContexts(), that provides the client with
information about the context in which code completion has occurred
and what kinds of entities make sense as completions at that
point. Patch by Connor Wakamo!
llvm-svn: 134615
CXTranslationUnit_NestedMacroInstantiations, which indicates whether
we want to see "nested" macro instantiations (e.g., those that occur
inside other macro instantiations) within the detailed preprocessing
record. Many clients (e.g., those that only care about visible tokens)
don't care about this information, and in code that uses preprocessor
metaprogramming, this information can have a very high cost.
Addresses <rdar://problem/9389320>.
llvm-svn: 130990
which determines whether a particular file is actually a header that
is intended to be guarded from multiple inclusions within the same
translation unit.
llvm-svn: 130808
Cygwin's ctype.h says;
/* These macros are intentionally written in a manner that will trigger
a gcc -Wall warning if the user mistakenly passes a 'char' instead
of an int containing an 'unsigned char'.
(snip) */
llvm-svn: 127308
clang_getCursor() via -cursor-at=??? and CINDEXTEST_EDITING is set in
the environment. This mirrors how we test code completion and
source-loading in the presence of this environment variable.
llvm-svn: 120392
but to wrap both an ASTUnit and a "string pool"
that will be used for fast USR generation.
This requires a bunch of mechanical changes, as
there was a ton of code that assumed that CXTranslationUnit
and ASTUnit* were the same.
Along with this change, introduce CXStringBuf,
which provides an llvm::SmallVector<char> backing
for repeatedly generating CXStrings without a huge
amount of malloc() traffic. This requires making
some changes to the representation of CXString
by renaming a few fields (but keeping the size
of the object the same).
llvm-svn: 119337
caching global code-completion results. In particular, don't perform
either operation the first time we parse, but do both after the first
reparse.
llvm-svn: 119285
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
Take 2: this time, adjusted tests appropriately and used a "simple"
approach to the spelling location.
llvm-svn: 118495
location where we're spelling a token even within a
macro. clang_getInstantiationLocation() tells where we instantiated
the macro.
I'm still not thrilled with the CXSourceLocation/CXSourceRange APIs,
since they gloss over macro-instantiation information.
llvm-svn: 118492
inclusion directives, keeping track of every #include, #import,
etc. in the translation unit. We keep track of the source location and
kind of the inclusion, how the file name was spelled, and the
underlying file to which the inclusion resolved.
llvm-svn: 116952
The problem was that text files were open in text mode and Microsoft implementation of fread and write will try to do nasty line-feed conversion which make the line position no longer valid. The fix is to read and write files in binary mode.
llvm-svn: 116286
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
produces a simple "display" name that captures the
arguments/parameters for a function, function template, class
template, or class template specialization.
llvm-svn: 115428
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
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
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
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
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
