Language features like erasing concrete metatype
values are also left for the future. Still, baby steps.
The singleton ordinary metatype for existential types
is still potentially useful; we allow it to be written
as P.Protocol.
I've been somewhat cavalier in making code accept
AnyMetatypeType instead of a more specific type, and
it's likely that a number of these places can and
should be more restrictive.
When T is an existential type, parse T.Type as an
ExistentialMetatypeType instead of a MetatypeType.
An existential metatype is the formal type
\exists t:P . (t.Type)
whereas the ordinary metatype is the formal type
(\exists t:P . t).Type
which is singleton. Our inability to express that
difference was leading to an ever-increasing cascade
of hacks where information is shadily passed behind
the scenes in order to make various operations with
static members of protocols work correctly.
This patch takes the first step towards fixing that
by splitting out existential metatypes and giving
them a pointer representation. Eventually, we will
need them to be able to carry protocol witness tables
Swift SVN r15716
With this in place, remove the hacks that peeked at the imported Clang
node to determine the selector for a method. We're all
attribute-driven now. Part of <rdar://problem/16019773>.
Swift SVN r15663
...instead of building our own from the argument patterns. This is all likely
to change soon, so let's not keep a separate implementation in PrintAsObjC.
In that vein, print subscript accessors the same way as any other methods.
No functionality change, except that subscript setter arguments are not all
called "value" any more.
Swift SVN r15532
of those to Class)
I would not call this a regression because the fix is very simple -- just mark
the class @objc, but in return the user will get concrete types on the
Objective-C side, which is a significant benefit.
Swift SVN r15234
This is the same as the previous commit, but for protocols. To do this I
had to modify the ObjC printer to include a SWIFT_PROTOCOL annotation like
the SWIFT_CLASS annotation already in use. This is probably a good thing
anyway.
Second half of <rdar://problem/16296027>
Swift SVN r14985
This means more duplication, but it's also more future-proof: the set of
features used is based on the compiler that generates the header, not the
compiler that eventually consumes the header. To allow for forward-
compatibility, all the macros used by the header can be overridden by the
consuming environment, and the header <swift/objc-prologue.h> will be
included if it exists.
Swift SVN r14893
...when the optional object type is a class or Objective-C protocol type.
This is currently hidden behind -enable-objc-optional because I didn't test
if the generated code is actually correct.
Also add PrintAsObjC support for these.
Known missing pieces: blocks, and Swift structs bridged to Objective-C classes
(right now, just String).
Swift SVN r14416
This is using the compatibility macro SWIFT_CLASS, so older Clangs can still
parse a generated header on its own. This will only be interesting in a
mixed-source target, where we may need to merge a forward declaration with
a Swift-generated @interface. (See <rdar://problem/16076729>.)
Swift SVN r14411
This is a bit ironic considering we're importing NSUInteger as Int rather
than UInt, but Swift should never be using the headers it prints anyway.
Swift SVN r14088
