[swift-dev] Proposal: Allow @objc(name) on enum declarations

[Kevin Ballard]

(moved to swift-dev)

I went ahead and implemented this over the weekend, but ran into some
weird behavior when testing it. I defined a new macro

# if defined(__has_feature) && __has_feature(generalized_swift_name)
# define SWIFT_ENUM_NAMED(_type, _name, SWIFT_NAME) enum _name : _type
# _name; enum SWIFT_COMPILE_NAME(SWIFT_NAME) SWIFT_ENUM_EXTRA _name :
# _type else define SWIFT_ENUM_NAMED(_type, _name, SWIFT_NAME)
# SWIFT_ENUM(_type, _name) endif

and taught ClangImporter to handle macros named SWIFT_ENUM_NAMED in
addition to SWIFT_ENUM, and then I generated a header that contains

typedef SWIFT_ENUM_NAMED(NSInteger, FooBar, "Bar") {  FooBarBaz = 0,
FooBarQux = 1, };

When I add a module.modulemap and import the module into the swift
integrated REPL, :print_module shows the enum

enum Bar : Int {  init?(rawValue: Int)  var rawValue: Int {    get {}  }
case FooBarBaz  case FooBarQux }

(I haven't touched case prefix stripping; presumably it's trying to
strip the Swift name instead of the ObjC name)

But if I actually try and reference the type Bar, it tells me it's an
undeclared type! I tried dumping the importer lookup table with swift-ide-
test, and while I don't actually understand the output format, from
looking at the IDE/dump_swift_lookup_tables.swift test, I get the
impression that the following is wrong (emphasis mine):

<<Bridging header lookup table>> Base name -> entry mappings:  Bar:
TU: FooBar *  FooBar: * *    TU: FooBar, FooBar** * **  FooBarBaz:
FooBar: FooBarBaz  FooBarQux:    FooBar: FooBarQux

I suspect that using __attribute__((swift_name)) was never tested with
enums, because there's no pre-existing enum macro that supports it.
Should I just file this as a bug and submit my PR as-is? Or do you have
any guidance on what might be going on here?

-Kevin Ballard

On Fri, Dec 11, 2015, at 10:05 PM, Douglas Gregor wrote:
>
> Hrm, that’s a good point. The generalized swift_name support is
> implemented in upstream Clang, but you’re right that Xcode 7.2 won’t
> be able to parse it. We can add a “__has_feature” entry for
> generalized swift_name in Clang and wrap this particular use of
> swift_name in
>
> #if __has_feature(generalized_swift_name) // ... #endif
>
>> I'm also not sure offhand where you actually put the attribute on an
>> enum, since the enum definition is actually 2 declarations, one for
>> the typedef and one for the enum itself. Would it go after the `enum`
>> keyword, in the place where SWIFT_ENUM_EXTRA is?
> Yes, that’s correct.
>
> - Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151214/7191f8d3/attachment.html>