When an @_implementationOnly import includes Objective-C categories
for existing types, it's useful to be able to override the members
provided in those categories without exposing them to clients of the
framework being built. Allow this as long as the overriding
declaration is marked as @_implementationOnly itself, with an
additional check that the type of the declaration does not change.
(Normally overrides are allowed to change in covariant ways.)
Part of rdar://50827914
Without -enable-resilient-objc-class-stubs, don't print classes with
resilient ancestry at all, since they're not actually visible to
Clang and referencing one will not actually work.
When the flag is specified, such classes do appear in the generated
header with the new objc_class_stub Clang attribute.
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
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
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
We were printing getter/setter names when the property came from
Objective-C initially, which is incorrect: we should print them when
the names differ from what Objective-C would compute by default. This
finishes rdar://problem/19408726, which was mostly in place a while
ago.
Swift SVN r28783
...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
