[cfe-dev] Missing Availability Information for Enums

Douglas Gregor dgregor at apple.com
Fri Apr 12 11:36:07 PDT 2013

On Apr 12, 2013, at 9:35 AM, Jordan Rose <jordan_rose at apple.com> wrote:

> On Apr 11, 2013, at 22:19 , Douglas Gregor <dgregor at apple.com> wrote:
>> On Mar 18, 2013, at 6:54 PM, Jordan Rose <jordan_rose at apple.com> wrote:
>>> On Mar 18, 2013, at 18:52 , Richard Smith <richard at metafoo.co.uk> wrote:
>>>> When built in C++11 mode, we get this, which looks much more reasonable:
>>>> TranslationUnitDecl 0x5e9b0d0 <<invalid sloc>>
>>>> |-TypedefDecl 0x5e9b610 <<invalid sloc>> __int128_t '__int128'
>>>> |-TypedefDecl 0x5e9b670 <<invalid sloc>> __uint128_t 'unsigned __int128'
>>>> |-TypedefDecl 0x5e9ba30 <<invalid sloc>> __builtin_va_list '__va_list_tag [1]'
>>>> |-TypedefDecl 0x5e9ba90 <tmp.c:1:1, col:14> NSInteger 'long'
>>>> |-EnumDecl 0x5e9bb10 <line:2:9, col:14> PKPassKitErrorCode 'NSInteger':'long'
>>>> |-TypedefDecl 0x5e9bc10 <col:1, col:45> PKPassKitErrorCode 'enum PKPassKitErrorCode':'enum PKPassKitErrorCode'
>>>> `-EnumDecl 0x5e9bca0 prev 0x5e9bb10 <col:65, line:7:1> PKPassKitErrorCode 'NSInteger':'long'
>>>>   |-AvailabilityAttr 0x5ecea50 <col:18, col:49> ios 6.0 0 0 ""
>>>>   |-EnumConstantDecl 0x5e9bd80 <line:3:5, col:23> PKUnknownError 'enum PKPassKitErrorCode'
>>>>   | `-ImplicitCastExpr 0x5e9bd68 <col:22, col:23> 'NSInteger':'long' <IntegralCast>
>>>>   |   `-UnaryOperator 0x5e9bd48 <col:22, col:23> 'int' prefix '-'
>>>>   |     `-IntegerLiteral 0x5e9bd28 <col:23> 'int' 1
>>>>   |-EnumConstantDecl 0x5ece960 <line:4:5, col:26> PKInvalidDataError 'enum PKPassKitErrorCode'
>>>>   | `-ImplicitCastExpr 0x5ece940 <col:26> 'NSInteger':'long' <IntegralCast>
>>>>   |   `-IntegerLiteral 0x5e9bdd0 <col:26> 'int' 1
>>>>   |-EnumConstantDecl 0x5ece9b0 <line:5:5> PKUnsupportedVersionError 'enum PKPassKitErrorCode'
>>>>   `-EnumConstantDecl 0x5ecea00 <line:6:5> PKInvalidSignature 'enum PKPassKitErrorCode'
>>> Hm, may be an implementation quirk in Objective-C's version of forward-declared enums, then. Not sure if accidental or by design. Doug, do you happen to know offhand?
>> I ran this with top-of-tree Clang under Objective-C, and I see:
>> |-TypedefDecl 0x7fcc2a827a90 <t.m:1:1, col:14> NSInteger 'long'
>> |-EnumDecl 0x7fcc2a827b10 <line:3:9, col:14> PKPassKitErrorCode 'NSInteger':'long'
>> |-TypedefDecl 0x7fcc2a859630 <col:1, col:45> PKPassKitErrorCode 'enum PKPassKitErrorCode':'enum PKPassKitErrorCode'
>> `-EnumDecl 0x7fcc2a8596a0 prev 0x7fcc2a827b10 <col:65, line:8:1> PKPassKitErrorCode 'NSInteger':'long'
>>   |-AvailabilityAttr 0x7fcc2a859900 <col:18, col:49> ios 6.0 0 0 ""
>>   |-EnumConstantDecl 0x7fcc2a859780 <line:4:5, col:23> PKUnknownError 'NSInteger':'long'
>>   | `-ImplicitCastExpr 0x7fcc2a859768 <col:22, col:23> 'NSInteger':'long' <IntegralCast>
>>   |   `-UnaryOperator 0x7fcc2a859748 <col:22, col:23> 'int' prefix '-'
>>   |     `-IntegerLiteral 0x7fcc2a859728 <col:23> 'int' 1
>>   |-EnumConstantDecl 0x7fcc2a859810 <line:5:5, col:26> PKInvalidDataError 'NSInteger':'long'
>>   | `-ImplicitCastExpr 0x7fcc2a8597f0 <col:26> 'NSInteger':'long' <IntegralCast>
>>   |   `-IntegerLiteral 0x7fcc2a8597d0 <col:26> 'int' 1
>>   |-EnumConstantDecl 0x7fcc2a859860 <line:6:5> PKUnsupportedVersionError 'NSInteger':'long'
>>   `-EnumConstantDecl 0x7fcc2a8598b0 <line:7:5> PKInvalidSignature 'NSInteger':'long'
>> which looks correct (and identical to what happens in C++11 mode). I suspect that Sebastian's headers aren't expanding NS_ENUM the same way in Objective-C as in Objective-C++11.
> NS_ENUM isn't defined the same in Objective-C as in Objective-C++. 
> #define NS_ENUM(_type,_name) enum _name : _type _name; enum _name : _type
> vs.
> #define NS_ENUM(_type,_name) _type _name; enum
> This has come up before—something about conversions. But aha! In Objective-C++, the enum is unnamed. Could that be part of the problem?

Okay, so take:

typedef NS_ENUM(NSInteger, PKPassKitErrorCode) {
    PKUnknownError = -1,
    PKInvalidDataError = 1,

and expand that out based on the latter #define and you get:

typedef NSInteger PKPassKitErrorCode; 

enum {
    PKUnknownError = -1,
    PKInvalidDataError = 1,
} __attribute__((availability(ios,introduced=6.0)));

with the AST

|-TypedefDecl 0x7fe243027a90 <t.m:1:1, col:14> NSInteger 'long'
|-TypedefDecl 0x7fe243027b10 <line:9:1, col:28> PKPassKitErrorCode 'NSInteger':'long'
`-EnumDecl 0x7fe243027b60 <line:6:43, line:14:1>
  |-AvailabilityAttr 0x7fe2430597d0 <col:18, col:49> ios 6.0 0 0 ""
  |-EnumConstantDecl 0x7fe243059670 <line:10:5, col:23> PKUnknownError 'int'
  | `-UnaryOperator 0x7fe243059650 <col:22, col:23> 'int' prefix '-'
  |   `-IntegerLiteral 0x7fe243059630 <col:23> 'int' 1
  |-EnumConstantDecl 0x7fe2430596e0 <line:11:5, col:26> PKInvalidDataError 'int'
  | `-IntegerLiteral 0x7fe2430596c0 <col:26> 'int' 1
  |-EnumConstantDecl 0x7fe243059730 <line:12:5> PKUnsupportedVersionError 'int'
  `-EnumConstantDecl 0x7fe243059780 <line:13:5> PKInvalidSignature 'int'

The availability attribute is (correctly) on the anonymous enum… but there's nothing whatsoever that relates the typedef (PKPassKitErrorCode) to the anonymous enum in the source code. 

Why aren't the two connected? Because PKPassKitErrorCode needs to have the underlying type NSInteger to be sure that it's the right size, and neither straight C nor C++ provide enumerations with a fixed underlying type. C++11 and Objective-C do allow enumerations with a fixed underlying type, so we can address this problem without having to split the typedef from the enum.

	- Doug

More information about the cfe-dev mailing list