Rely on Foundation to provide NS_ARRAY/NS_DICTIONARY/NS_SET macros
that expand to either an unspecialized type (e.g., NSArray *) or a
specialized one (e.g., NSArray<T> *) as appropriate for the definition
of NSArray. Use these macros in the Objective-C printer.
The actual names and form of these macros is still to be debated, but
it's important to be able to handle both Clangs and Foundations with
and without parameterized NSArray/NSDictionary/NSSet.
Swift SVN r24198
If enums are used as parameters or returns of @objc methods, we may need to forward declare those enums when printing the class @interface.
Swift SVN r23445
Thanks Jordan for pointing out that the test didn't in fact test that we imported ObjC-ified Swift decls back to the same type. Adjust things so that we do, putting the annotation attribute in the right place, and fixing a crash when we have superfluous typedefs for native Swift decls.
Swift SVN r23439
This is necessary for @objc enums because, for C compatibility, the representations of the cases must match their raw values. We might want to do this for sufficiently fragile Swift enums in the future too, but that can wait. This lets us successfully print the raw values as ObjC.
Swift SVN r23423
Predefine a SWIFT_ENUM macro that expands the same as NS_ENUM, but which we can use to recognize Swift-defined @objc enums that are imported back. Print enums as ObjC using this SWIFT_ENUM macro.
We currently don't serialize the raw value exprs of enums, so we fail to correctly bring raw values from the enum declaration to the ObjC version.
Swift SVN r23422
...and use #pragma clang diagnostic when otherwise unavoidable.
As part of this change, start testing generated headers under
-Weverything -Werror, with targeted exceptions.
rdar://problem/18332948
Swift SVN r22010
While Foundation actually defines the NSZone typedef and what you can do with
it, the ObjectiveC module makes use of it in its raw form: "struct _NSZone *".
To avoid a circular dependency, sink our adapter down to the ObjectiveC
overlay.
Swift SVN r21827
This reduces the chances of conflict among inner class names. It's too easy
for a class to be implicitly marked @objc in Swift.
To make this work, correctly preserve the implicitness of @objc through
serialization. (We were probably intending to do this all along, since we
were serializing the flag but not doing anything with it at the other end.)
Swift SVN r21678
There are still problems with nested classes:
- They're much more likely to have colliding compile-time names
(since the outer class's name is dropped).
- They're only picked up if the outer class is also @objc.
But at least now we won't generate invalid Objective-C. Unless the inner
classes have the same name.
rdar://problem/18187877
Swift SVN r21677
ownership attributes by bracketting
header with specific group warning pragma clang.
This patch also requires patch for rdar://17845264
which is currently in TOT. This is //rdar://17023083
Swift SVN r20767
"...because the generated header for a framework is part of the framework's
public Objective-C interface, only declarations marked public appear in the
generated header for a Swift framework."
Just missed a case here when we decided to do things this way.
<rdar://problem/17796727>
Swift SVN r20653
To do this, we keep track of decls with superfluous typedefs (rather than
just the typedefs), and check for that. Tag decls without typedefs are
printed with the tag.
<rdar://problem/17569385>
Swift SVN r20221
weak => 'weak', unless the type is a CF type. I'm not sure weak references to
CF types work anyway, but until we have that cleared up this works.
unowned => 'assign'. In Objective-C, use of 'assign' for object properties is
largely deprecated in favor of 'unsafe_unretained', but unowned
properties behave more like a 'safe_unretained'. Since they don't
auto-update like 'weak', though, this should hint to clients to
be careful about lifetimes.
unowned(unsafe) => 'unsafe_unretained'
As before, Arrays, Dictionaries, and Strings are considered 'copy' properties;
blocks are now considered 'copy' properties as well.
All other types get their (implied) default: 'strong' for objects, 'assign'
for primitives.
<rdar://problem/17346846>
Swift SVN r20112
Also, fix a bug where value properties weren't getting marked as "copy"
if wrapped in IUOs, and replace some identifier-based comparisons with
pointer comparisons against ASTContext-cached decls.
<rdar://problem/17007235>
Swift SVN r19874
attribute is a "modifier" of a decl, not an "attribute" and thus shouldn't
be spelt with an @ sign. Teach the parser to parse "@foo" but reject it with
a nice diagnostic and a fixit if "foo" is a decl modifier.
Move 'dynamic' over to this (since it simplifies some code), and switch the
@optional and @required attributes to be declmodifiers (eliminating their @'s).
Swift SVN r19787
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.
The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.
Swift SVN r19763
You can still mark them @objc explicitly (or @IBOutlet, or anything else that
would require ObjC interop).
Also, don't print private decls in the generated header, whether @objc or not.
not.
Swift SVN r19733
- Category names weren't unique.
- We were using an attribute to detect if something was a Swift category,
but attributes can't be used on categories.
- The test that this was all working was failing in a way that wasn't caught.
To solve these problems:
- We're using a macro to generate category names based on __LINE__ in addition
to the current module.
- The importer uses the macro to detect that the category comes from Swift
(no attribute needed).
- The test now has a deliberate error for -verify to catch.
<rdar://problem/17342287&17538553>
Swift SVN r19479
Because extensions don't have any identity we can check against, we can't
tell when we see an Objective-C category if it came from a Swift extension.
Change PrintAsObjC to mark all such categories with SWIFT_EXTENSION, and
just skip them unilaterally when importing Objective-C code.
Also, actually give Swift extensions a name when writing them as Objective-C
categories. Previously, they were nameless categories ("class extensions"),
but methods in a class extension are supposed to be implemented in the class's
main @implementation, so people were getting unexpected warnings about missing
implementations.
<rdar://problem/17342287>
Swift SVN r19116
.../if/ the protocol and the class are from the same top-level Clang module.
If not, the protocol is /not/ renamed, and users will have to disambiguate
with module qualification.
This kills our hardcoded "RenamedProtocols" list; it turns out this pattern
is more common than we thought /and/ leads to cross-referencing issues.
<rdar://problem/16206627>
Swift SVN r18809
...and just outright import the bridging header if that's what's needed.
This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.
<rdar://problem/17183425>
Swift SVN r18795
