Swift's bridged collections are allowed to store objects of non-@objc
classes, e.g., an array of (non-@objc) Swift classes is still bridged
to NSArray. Deal with such cases by printing out the type as "NSArray
*", since we cannot name the type in Objective-C to provide a more
specialized NSArray type.
This is a fairly narrow fix for rdar://problem/20392771 that needs
more discussion.
Swift SVN r26905
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
That's a C11 feature, and we can't force everyone to enable C11 just yet.
Instead, go back to the old way of using "enum Foo" to refer to @objc enums
defined in Swift. Just don't do it unilaterally for non-@objc enums.
Should unstick the buildbot.
Swift SVN r25161
For pointer types that Swift doesn't currently import using Optional
(see rdar://problem/15189170 and its dups), use __null_unspecified.
rdar://problem/19775335
Swift SVN r25144
...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
Previously, when dealing with CF typedefs of other CF types, we would strip
off the "Ref" suffix...and then leave it off when it came time to print the
Objective-C header.
rdar://problem/19446942
Swift SVN r24562
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
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
