[cfe-dev] querying information about preprocessing directives in libclang

[Ted Kremenek]

Hi Stefan,

Sorry for the delay in responding.  Comments inline.

On Mar 27, 2011, at 2:38 PM, Stefan Seefeld wrote:

> libclang defines cursor kinds for various preprocessing directives. 
> However, I can't seem to find any means to access information about 
> those directives themselves.
> 
> What I'd like to query is:
> 
> * from include directives:
>    - the kind of directive (e.g., "include", "include_next")

This information isn't currently exposed.  We have a couple options.  We could expose another CXCursorKind, or have an API to query more information from a CXCursor with kind CXCursor_InclusionDirective.  I'd prefer the former, but I think it's worth asking what kind of information you'd want to discern here between these two directives.

>    - the file name being included, in its symbolic form (the path as 
> written)
>    - the actual filename (full path) being resolved.

clang_getIncludedFile() will return the latter.  There is no API to return the former right now, but it could be added.  Internally it would likely require relexing, as I don't believe that Clang retains that information in the AST or Preprocessor.

> * from macro definitions:
>   - the type of macro (object-like, function-like)

This is currently not exposed, but likely could be easy to add.

>   - the parameter list

I don't believe there is an API for this (yet).  What specifically are you looking for?  The parameter list is raw text without semantic meaning until it is instantiated.

>   - the macro definition body

This is also raw text with no semantic meaning.

clang_getCursorExtent() should return the full extent (range) for a CXCursor.  If you query this on a macro definition cursor (CXCursor_MacroDefinition), does it not provide you the full range?  If not, that's likely a bug.

> 
> * from macro instantiation:
>   - a reference to the definition

clang_getCursorReferenced() will map from a macro instantiation cursor the macro definition.


> 
> Is any of this already available through libclang ? If not, is it planned ?
> 
> If neither, is there another API that's more suitable to find this 
> information ?

I think most of this is already exposed, and the rest of it would be straightforward to add.  The API has grown incrementally as needs arose.  libclang is definitely the right API that we want to generalize for these kind of queries.

For the APIs that don't exist, it's worth filing LLVM bug reports as feature requests so we can track their resolution.  If you feel comfortable diving into the implementation of libclang (e.g., CIndex.cpp), it is probably straightforward to implement most of these.