<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Mon, Dec 14, 2015, at 09:34 PM, Douglas Gregor wrote:<br></div>
<blockquote type="cite"><div> </div>
<div><blockquote type="cite"><div>On Dec 14, 2015, at 6:52 PM, Kevin Ballard <<a href="mailto:kevin@sb.org">kevin@sb.org</a>> wrote:<br></div>
<div> </div>
<div><div><div>(I haven't touched case prefix stripping; presumably it's trying to strip the Swift name instead of the ObjC name)<br></div>
</div>
</div>
</blockquote><div> </div>
<div>Probably. It’s not actually clear which prefix it should try stripping with.<br></div>
</div>
</blockquote><div> </div>
<div>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).<br></div>
<div> </div>
<blockquote type="cite"><div><blockquote type="cite"><div><div><div>But if I actually try and reference the type Bar, it tells me it's an undeclared type!<br></div>
</div>
</div>
</blockquote><div> </div>
<div>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.<br></div>
</div>
</blockquote><div> </div>
<div>Ah ok. I assumed that because there was code in here to look for the attribute that it was expected to work.</div>
<div> </div>
<blockquote type="cite"><div><div>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?<br></div>
</div>
</blockquote><div> </div>
<div>Should I be swift_name'ing the typedef too?<br></div>
<div> </div>
<div>As for the duplication, that actually matches the output from the IDE/dump_swift_lookup_tables.swift file. Given the following Obj-C declaration:<br></div>
<div> </div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;">// Renaming enumerations.<br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;">SWIFT_ENUM(unsigned char, SNColorChoice) {<br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;"> SNColorRed SWIFT_NAME(Rouge),<br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;"> SNColorGreen,<br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;"> SNColorBlue<br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;">};<br></span></div>
<div> </div>
<div>The test explicitly looks for<br></div>
<div> </div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;">// CHECK-NEXT: SNColorChoice:</span><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;"><br></span></div>
<div><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;">// CHECK-NEXT: TU: SNColorChoice, SNColorChoice</span><span class="font" style="font-family: menlo, consolas, "courier new", monospace, sans-serif;"><br></span></div>
<div> </div>
<div>The thing that was weird in my case was that it was using the name FooBar instead of Bar.</div>
<div> </div>
<div><blockquote type="cite"><div><div>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.<br></div>
</div>
</blockquote><div> </div>
<div>Ok, I'll figure out what tests I can write now for this and I'll submit the PR soon (probably tomorrow evening).<br></div>
<div> </div>
<div>-Kevin Ballard</div>
</div>
<div> </div>
</body>
</html>