[cfe-dev] libclang: token annotation

MichaƂ Staromiejski michal.staromiejski at gmail.com
Fri May 25 06:03:38 PDT 2012

Hi everyone!

First of all, thank you for libclang ;)

I'm working on semantic highlight plugin for Code::Blocks IDE based on
So far, everything works quite well, but I've noticed some issues with
the functions clang_annotateTokens and (this is probably more specific)

I'm using svn version (rev. 157460) but the same is with 3.1.

>From the documentation:
"clang_getCursor() maps an arbitrary source location within a translation
unit down to the most specific cursor that describes the entity at that

And the weird things begin. Consider the following (valid) C++ code:

#ifdef _MY_MACRO_
#define NUM 2
#define NUM 5

template <class T>
class A
#ifdef _MY_MACRO_ // (1)
    int a; // (2)
    bool a;

    static bool array[NUM]; // (3)
    operator T();

template <class T> // (4)
bool A<T>::array[NUM]; // (5)

bool g(A<bool> a)
    return a; // (6)

template <class T> // (4)
T f(A<T> a)
    return a;

Using clang_annotateTokens (clang_getCursor) or c-index-test
-test-annotate-tokens (-cursor-at, resp.) everything but the following is

(1) Inside any block (class, struct, namespace, ... declaration, function
body, etc.) preprocessor directives
are not annotated as such.
(2) If the macro _MY_MACRO_ is not defined, all tokens in "int a;" are
annotated in same way as the block they belong to;
shouldn't they be annotated as, for example, CXXCursor_InactiveCode (new
CXCursorKind value)?
(3) It's weird but here clang_annotateTokens behaves different from
c-index-test: the former annotates the 'NUM' token
as 'VarDecl=array' (wrong) and the latter as 'macro expansion=NUM', as
(4) The whole line is annotated here with CXCursor_FirstInvalid (70) and
this concerns all such 'template' lines.
(5) The whole line is marked as 'VarDecl=array' (IHMO 'A' should be
'TemplateRef=A' and 'T' should be 'TypeRef=T', 'NUM' behaves similarly as
in (3)).
(6) 'a' is annotated as 'CallExpr=operator _Bool', shouldn't be
'DeclRefExpr=a'? It is weird, but in the function 'f' there is no such

Is it a bug or do I miss something?

Michal Staromiejski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120525/067b6e24/attachment.html>

More information about the cfe-dev mailing list