[cfe-commits] libclang: Patch to get an integer value from a cursor.

[Vinay Sajip]

>________________________________
>From: Argyrios Kyrtzidis <kyrtzidis at apple.com>
>
>Merging unrelated functionality in one function does not seem ideal.
>
>
>How about:
>-actually expose the attributes that you are interested in
>-adding clang_getConstantValue(CXCursor) where CXCursor can be a decl with an init value (like CXCursor_EnumConstantDecl) or a constant-folded expression.
>-adding clang_getBitfieldWidth(CXCursor) where CXCursor is a FieldDecl (separate function otherwise there may be some difficulty distinguishing between a bitfield width and an in-class initializer)

I agree in principle, but I wasn't sure how a widened API (i.e. one with more entry points) would be received. I have at least three values that I need to get out of the AST:

1. Enumeration constants.
2. Bit field widths.
3. Declaration attributes such as calling conventions or inlining directives.

So, I would think an API such as the following would be appropriate for the first two:


long long clang_getConstantValue(CXCursor);
int clang_getBitFieldWidth(CXCursor); // int seems reasonable for a bit field width, do you prefer Bitfield over BitField?

For declaration attributes, these are stored as separate unexposed attribute nodes at the moment. So we could add an API

int clang_getAttributeValue(CXCursor);

which returns -1 for non-attribute nodes and the appropriate attribute kind for attribute nodes. However, as these values are currently unexposed in the libclang API, they are prone to change and there isn't a mapping between internal values and external values (for example IIRC the AlwaysInline attribute has changed from 8 to 9 since I started working with clang, which is fairly recently). This suggests that a clang_getAttributeKind API is required to map from internal values to an unchanging external set of values such as e.g. CXAttribute_AlwaysInline. I've tried to keep API additions to a minimum as at the moment I'm finding that a lot of time is spent in conflict resolution when rebasing/merging with origin/master. I'm not sure why this is - I'm not as familiar with Git as I am with Mercurial but I'm following what I understand to be best practice.

Your comments on the API suggestions above would be appreciated.
Regards,

Vinay Sajip