Skip to content

Conversation

jrose-apple
Copy link
Contributor

  • Explanation: If an imported type has been renamed between Swift 3 and Swift 4, both names are available for use in Swift 3.2, with the "old" name being a typealias for the new name. PrintAsObjC, however, didn't expect to see typealiases with Clang nodes that weren't typedefs or Objective-C classes. Add support for these kinds of typealiases by doing the same thing we'd do for an underlying struct type.
  • Scope: Affects use of typealiases created by the ClangImporter in APIs that are exposed in the generated Objective-C header.
  • Radar: rdar://problem/32514335
  • Reviewed by: @milseman
  • Risk: Low. Uses existing code paths to handle this case.
  • Testing: Passed compiler regression test, confirmed that the original test case now generates correct headers.

…lang#10042)

These are TypeAliasDecls whose Clang nodes are not TypedefNameDecls.
This worked all right for classes, but dropped the tag keyword
(e.g. 'struct') for tag decls with names of their own, and didn't
print any name at all for C types that used the
typedef-for-anonymous-tag pattern.

rdar://problem/32514335
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@tkremenek
Copy link
Member

@swift-ci test source compatibility

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@tkremenek tkremenek merged commit 88a5656 into swiftlang:swift-4.0-branch Jun 2, 2017
@jrose-apple jrose-apple deleted the 4.0-anonymous-structs-causing-problems-once-again branch June 2, 2017 00:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants