[cfe-commits] [PATCH] Fix name clash (Name clash causing troubles)

[Jordan Rose]

On Jul 2, 2012, at 8:22 AM, Dmitri Gribenko wrote:

> On Sat, Jun 30, 2012 at 11:08 AM, Jordan Rose <jordan_rose at apple.com> wrote:
>> On Jun 30, 2012, at 2:31 AM, Dmitri Gribenko wrote:
>>> On Sat, Jun 30, 2012 at 12:55 AM, Enea Zaffanella
>>> <zaffanella at cs.unipr.it> 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