On Sep 23, 2011, at 7:13 AM, Vinay Sajip wrote: >> ________________________________ >> From: Argyrios Kyrtzidis <[email protected]> >> >> 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?
"Bitfield" seems to be the convention in AST, though it's not consistent everywhere. > > 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. When I said "expose the attributes" I meant adding the attributes that you are interested in CXCursorKind, see: CXCursor_UnexposedAttr = 400, CXCursor_IBActionAttr = 401, CXCursor_IBOutletAttr = 402, CXCursor_IBOutletCollectionAttr = 403, CXCursor_CXXFinalAttr = 404, CXCursor_CXXOverrideAttr = 405, CXCursor_LastAttr = CXCursor_CXXOverrideAttr, We can add new ones here. > > Your comments on the API suggestions above would be appreciated. > Regards, > > Vinay Sajip > > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
