On Jul 2, 2012, at 8:22 AM, Dmitri Gribenko wrote: > On Sat, Jun 30, 2012 at 11:08 AM, Jordan Rose <[email protected]> wrote: >> On Jun 30, 2012, at 2:31 AM, Dmitri Gribenko wrote: >>> On Sat, Jun 30, 2012 at 12:55 AM, Enea Zaffanella >>> <[email protected]> wrote: >>>> In include/clang/AST/RawCommentList.h we have >>>> >>>> class RawComment { >>>> public: >>>> enum CommentKind { >>>> CK_Invalid, ///< Invalid comment >>>> [...] >>>> >>>> In include/clang/AST/OperationKinds.h the following macro is defined >>>> >>>> #define CK_Invalid ((CastKind) -1) >>> >>> Hi Enea, >>> >>> Thank you for noticing! >>> >>> Here is a patch that should fix this. >>> >>> Please review. >>> >>> Dmitri >> >> It's possible the reason this isn't used is because CastKind would otherwise >> be only positive numbers and thus suitable for storing in an unsigned >> bitfield without complaint. Maybe ~0U would be a better choice of constant? > > Is there any reason why CK_Invalid has an all-ones value? (We could > add it to enum without an initializer)
I think it's just so it will never intersect with a valid value. If these constants are exposed in libclang, they're expected to remain stable. Then again, CK_Invalid probably may not be exposed in libclang even if the others are. I agree with Enea that it's probably not in the enum so that exhaustive switch statements can ignore it -- you should never actually be consuming a cast with CK_Invalid type. And in general I think I agree that we should try to have a different prefix for comment kinds: RC_ or RCK_, since both comment kinds and cast kinds /could/ show up in the same section of code. Jordan _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
