Sent from my iPhone
> On Dec 14, 2015, at 10:59 PM, Kevin Ballard <[email protected]> wrote: > >> On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote: >> >>> On Dec 14, 2015, at 6:52 PM, Kevin Ballard <[email protected]> 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). Note that you could grab the name directly from the Clang declaration with a small amount of effort, so it doesn't get translated at all. > >>> 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. I'm in the middle of implementing generalized swift_name support. importFullName is about a week old :) > >> 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? IMO, yes. We want both the enum and typedef to have the new name. > > 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 Sure. One is the enum, one is the typedef. > > The thing that was weird in my case was that it was using the name FooBar > instead of Bar. I expected one FooBar for the typedef. It's the other that surprised me. > >> 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). Okay! - Doug
_______________________________________________ swift-dev mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-dev
