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

[Kevin Ballard]

On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote:
>
>> On Dec 14, 2015, at 6:52 PM, Kevin Ballard <kevin at sb.org> wrote:
>>
>> (I haven't touched case prefix stripping; presumably it's trying to
>> strip the Swift name instead of the ObjC name)
>
> Probably. It’s not actually clear which prefix it should try
> stripping with.

It seems to me that it should strip the ObjC name, as the enum constants
will presumably be named after the ObjC enum name. I already went ahead
and implemented this earlier today and it works (I added an option to
ClangImporter::Implementation::importFullName called
ImportNameFlags::IgnoreSwiftNameAttr).

>> But if I actually try and reference the type Bar, it tells me it's an
>> undeclared type!
>
> Yeah, there is some known brokenness here: the swift_name attribute
> doesn’t actually work on global declarations, because the Clang
> importer currently makes assumptions about the mapping from Swift
> names to Objective-C names. That’s exactly why I’m introducing the
> Swift name lookup tables into the Clang importer now, because they
> make it possible for arbitrary renaming of Objective-C entities to
> actually work in Swift.

Ah ok. I assumed that because there was code in here to look for the
attribute that it was expected to work.

> Your macro is swift_name’ing the enum but not the typedef, which is
> why there are entries for both Bar -> FooBar and FooBar -> FooBar. The
> duplication in the FooBar result is interesting, though: perhaps it’s
> related to the fact that the enum is first declared without the
> swift_name attribute?

Should I be swift_name'ing the typedef too?

As for the duplication, that actually matches the output from the
IDE/dump_swift_lookup_tables.swift file. Given the following Obj-C
declaration:

// Renaming enumerations. SWIFT_ENUM(unsigned char, SNColorChoice) {
SNColorRed SWIFT_NAME(Rouge),  SNColorGreen,  SNColorBlue };

The test explicitly looks for

// CHECK-NEXT:   SNColorChoice: // CHECK-NEXT:     TU: SNColorChoice,
SNColorChoice

The thing that was weird in my case was that it was using the name
FooBar instead of Bar.

> It’s fine to submit a PR for this that tests what works (e.g., use
> FileCheck to verify that the Swift API dumps for the imported enum
> have the right names) and also have some tests that verify the bad
> behavior (“cannot find Bar”) with a FIXME to say that the test should
> succeed. That way, you can get your change in and move the needle
> forward a little, and when we start turning on the Swift name lookup
> tables, these tests will help us see that more things are working.

Ok, I'll figure out what tests I can write now for this and I'll submit
the PR soon (probably tomorrow evening).

-Kevin Ballard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151214/1d6b1a95/attachment.html>