Basically the current design is:
-for an implementation method, show as overridden the interface method.
This is not useful, and is inconsistent with the C++ side
-for an interface method, show as overridden the protocols methods (this is desirable)
and the methods from the categories; methods from categories are not useful
since they are considered the same method (same USR).
-If there is a protocol method or category method reported, it does not check the
super class for overridden methods. This is really problematic since
overridden methods from super class is what we want to give back.
Change clang_getOverriddenCursors to show as overridden any method in the class's
base class, its protocols, or its categories' protocols, that has the same
selector and is of the same kind (class or instance).
If no such method exists, the search continues to the class's superclass,
its protocols, and its categories, and so on. A method from an Objective-C
implementation is considered to override the same methods as its
corresponding method in the interface.
rdar://10967206
llvm-svn: 152270
the new Objective-C NSArray/NSDictionary/NSNumber literal syntax.
This introduces a new library, libEdit, which provides a new way to support
migration of code that improves on the original ARC migrator. We now believe
that most of its functionality can be refactored into the existing libraries,
and thus this new library may shortly disappear.
llvm-svn: 152141
- Exposes a CXType_Vector type kind for vector types.
- Adds generalized versions of the clang_getArrayElementType and clang_getArraySize functions, named clang_getElementType and clang_getNumElements, which work on array, vector, or complex types.
- Adds additional functions for querying function types. clang_isFunctionTypeVariadic returns true if a function type is variadic. clang_getFunctionCallingConv returns an enumeration value indicating the calling convention of the function type. clang_getNumArgTypes returns the number of static argument types, and clang_getArgType gets the type of an argument.
- Adds a clang_getTypedefDeclUnderlyingType function to get the underlying type from a TypedefDecl cursor.
- Adds a clang_getEnumDeclIntegerType function to get the integer type from an EnumDecl cursor.
- Adds clang_getEnumConstantDeclValue and clang_getEnumConstantDeclUnsignedValue functions to get the value of an EnumConstantDecl as a signed or unsigned long long, respectively.
- Exposes a CXCursor_AsmLabelAttr cursor kind for __asm__("label") attributes.
- Alters clang_getCursorSpelling to return the label value for AsmLabelAttr-kind cursors.
llvm-svn: 145972
-For indexDeclaration, also pass the declaration attributes as an array of cursors.
-Rename CXIndexOpt_OneRefPerFile -> CXIndexOpt_SuppressRedundantRefs, and only pass
a reference if a declaration/definition does not exist in the file.
-Other fixes.
llvm-svn: 144942
Cut down the number of callbacks to more generic ones. Clients can check
an enum to find out what kind of declaration it is and they can call functions
to get more specific information than the generic provided info.
llvm-svn: 144343
more of the work involved in indexing a translation unit and simplifies client
implementations.
Only C/ObjC for now, C++ (and comments) to come.
llvm-svn: 142233
-Allow cursor visitation of an attribute using its source range
-Add C++ 'final' and 'override' attributes as cursor kinds
-Simplify the logic that marks 'final' and 'override' attributes as tokens.
llvm-svn: 139609
system for macro-backed source locations. The old APIs are preserved for
legacy users.
This was intended to land with the main work of instantiation ->
expansion, but despite running it by Doug over a month ago, I forgot to
commit it. Very sorry for that...
llvm-svn: 138860
- buildPieces was return a C++ object from inside an extern "C". (MSVC didn't like that)
- clang_getCursorReferenceNameRange was missing a CINDEX_LINKAGE causing a link error.
llvm-svn: 135983
NestedMacroInstantiations -> NestedMacroExpansions.
With this change, libclang should be completely converted except for
uses of SourceManger and SourceLocation APIs, and the C bindings for
those APIs.
llvm-svn: 135149
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
MacroInstantiation -> MacroExpansion rename. Internally, everything is
switched.
Introduce a new cursor kind enum with the new name, but retain the old
name as an alias so that we don't break backwards compatibility.
Also update the debug printing routine to use 'macro expansions' as its
explicitly not guaranteed to be stable, and mechanically switch the test
cases over to that.
llvm-svn: 135140
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
Bendersky. Specifically:
* Implemented a new function in libclang: clang_isAttribute
* Fixing TranslationUnit.get_includes to only go through the argument
* buffer when it contains something. This fixed a crash on Windows
* clang_getFileName returns CXString, not char*. Made appropriate
* fixes in cindex.py - now the relevant tests pass and we can see the
* full locations correctly again (previously there was garbage in
* place of the file name)
* Exposed clang_getCursorDisplayName to the python bindings
llvm-svn: 134460
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
clang_getCursorLexicalParent() to cope with class and function
templates, along with the parent of the translation unit. Fixes PR8761
and PR8766.
llvm-svn: 122324
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
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
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
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
constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.
llvm-svn: 113545
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
three different kinds of AST nodes to represent using declarations:
UsingDecl, UnresolvedUsingValueDecl, and
UnresolvedUsingTypenameDecl. These three are collapsed into a single
cursor kind for using declarations, since libclang clients don't need
the distinction.
Several related changes here:
- Cursor visitation of the three AST nodes for using declarations
- Proper source-range computation for these AST nodes
- Using declarations have no USRs, since they don't actually declare
any entities.
llvm-svn: 112730
suppressing USRs). Also, fix up the source location information for
using directives so that the declaration location refers to the
namespace name.
llvm-svn: 112693
with a new cursor kind for a reference to a namespace.
There's still some oddities in the source location information for
NamespaceAliasDecl that I'll address with a separate commit, so the
source locations displayed in the load-namespaces.cpp test will
change.
llvm-svn: 112676
determines the kind of declaration that would be generated if the
given template were instantiated. This allows a client to distinguish
among class/struct/union templates and function/member function/static
member function templates.
Also, teach clang_CXXMethod_isStatic() about function templates.
llvm-svn: 112655
template. Such cursors occur, for example, in template specialization
types such as vector<int>. Note that we do not handle the
super-interesting case where the template name is unresolved, e.g.,
within a template.
llvm-svn: 112636
libclang. This includes:
- Cursor kind for function templates, with visitation logic
- Cursor kinds for template parameters, with visitation logic
- Visitation logic for template specialization types, qualified type
locations
- USR generation for function templates, template specialization
types, template parameter types.
Also happens to fix PR7804, which I tripped across while testing.
llvm-svn: 112604
conversion functions. This introduces new cursor kinds for these three
C++ entities, and reworks visitation of function declarations so that
we get type-source information for the names.
llvm-svn: 112600
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
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
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
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
directives while annotating tokens in CIndex. This functionality
should probably be factored out of this routine, but we're not there
yet.
llvm-svn: 98786
copy the source buffers provided rather than referencing them
directly, so that the caller can free those buffers immediately after
calling clang_createTranslationUnitFromSourceFile(). Otherwise, we
risk hitting those buffers later (when building source ranges, forming
diagnostics, etc.).
llvm-svn: 97296
knobs to control formatting. Eventually, I'd like to merge the
implementation of this code with the TextDiagnosticPrinter, so that
it's easy for CIndex clients to produce beautiful diagnostics like the
clang compiler does.
Use this new function to display diagnostics within c-index-test.
llvm-svn: 96603
we attach diagnostics to translation units and code-completion
results, so they can be queried at any time.
To facilitate this, the new StoredDiagnostic class stores a diagnostic
in a serializable/deserializable form, and ASTUnit knows how to
capture diagnostics in this stored form. CIndex's CXDiagnostic is a
thin wrapper around StoredDiagnostic, providing a C interface to
stored or de-serialized diagnostics.
I've XFAIL'd one test case temporarily, because currently we end up
storing diagnostics in an ASTUnit that's never returned to the user
(because it contains errors). I'll introduce a temporary fix for this
soon; the real fix will be to allow us to return and query invalid ASTs.
llvm-svn: 96592
diagnostic callback mechanism, so all diagnostics now go through that
callback. Also, eliminate the displayDiagnostics flag to
clang_createIndex(), since it is no longer necessary: the client
determines whether to display diagnostics or not.
llvm-svn: 94714
clients can format diagnostics as they wish rather than having to
parse standard error. All of the important parts of the front end's
diagnostics are exposed: text, severity, location, source ranges, and
fix-its. The diagnostics callback is now available with
clang_createTranslationUnitFromSource() and
clang_createTranslationUnit().
As part of this change, CXSourceLocation and CXSourceRange got one
pointer larger, since we need to hold on to the SourceManager and
LangOptions structures in the source location. This is the minimum
amount of information needed for the functions that operate on source
locations and ranges (as implemented now). Previously we held on to
the ASTContext, but the diagnostics callback can end up with source
locations when there is no ASTContext (or preprocessor).
Still to do:
- Code completion needs to support the diagnostics callback, once we
have the ability to (de-)serialize diagnostics.
- Eliminate the "displayDiagnostics" argument to createIndex; we'll
always pass diagnostics to the callback and let it deal with display.
llvm-svn: 94709
- Added more routines to manipulate/compare source locations and ranges
- Switched clang_getCursor() over to take a CXSourceLocation rather
than file/line/column.
llvm-svn: 94226
Argyrios Kyrtzidis