Since Swift 3 and Swift 4 might have different views of an Objective-C
API's nullability, we can end up with incompatible overrides,
including with inherited initializers. This is unfortunate but also
realistic; the Swift 3 code is /not/ set up to handle the new nullability
used by Swift 4 and Objective-C. Just silence the warning.
(It would be nice to not print inherited initializers at all, but that
would mean making sure there are no convenience initializers we have
to print as well. Otherwise the class would get mistaken for one
without explicit designated initializers.)
rdar://problem/32571301
For historic reasons, Clang's representation of an Objective-C class
declaration ObjCInterfaceDecl) and compatibility alias
(ObjCCompatibleAliasDecl) are not actually Clang TypeDecl nodes. Cope
with this in Objective-C printing, fixing rdar://problem/32308192.
I'm not sure why this didn't occur to me in 8282160d: of course if you
see a generic type with arguments, you need to see the @interface for
that type in order to supply the arguments. Maybe I was thinking the
generated interface would automatically import anything the module
itself imports, but that hasn't ever been true.
rdar://problem/28738008
More specifically, don't try to emit a definition for them. Just fall
through to what we do for forward-declarations...which also needed some
fixing, to make sure we don't use a Swift typealias as its underlying
type but never import the underlying type.
https://bugs.swift.org/browse/SR-2352
...and then fix our forward-declaration logic that assumed that they did.
This fixes a rare case where we would end up printing "enum" twice if the
user (benignly) misused NS_ENUM.
rdar://problem/19769964
Swift SVN r25143
If a property, method, or subscript overrides an imported property, method,
or subscript that was originally declared using NSUInteger as a property,
parameter, or return type, print the subclass's member using "NSUInteger"
in the generated header to prevent override warnings.
This doesn't handle all cases--in particular, it doesn't handle the
NSUInteger being nested inside a larger type--but it does get the easy
ones correct. I think the easiest way to be more correct would be to mark
NSUInteger-as-Int somehow using a distinct type. (Hidden attribute?
Another typealias? Not sure.)
rdar://problem/19321126
Swift SVN r24771
