An Objective-C subscript setter has a type of the form
(this) -> (value, index) -> ()
while a Swift subscript setter has a type of the form
(this) -> (index) (value) -> ()
Introduce a Swift "thunk" with the latter signature that simply calls
the underlying Objective-C method, and make sure that thunk gets
type-checked and IR-generated appropriately.
Swift SVN r3382
This commit covers only the AST-building side of indexed
subscripting, mapping objectAtIndexedSubscript: and
setObject:atIndexedSubscript: to Swift 'subscript' declarations. IR
generation and support for keyed subscripting to follow.
Swift SVN r3377
Only create constructors for class 'new' methods (not instance methods
like
newScriptingObjectOfClass:forValueForKey:withContentsValue:properties:),
and only do so when the class type inherits from NSObject. The latter
occurs because we don't have a notion of a 'top' for Objective-C
classes, and is a temporary measure.
Swift SVN r3374
Note that the constructors we emit don't function yet, since they rely
on the not-yet-implemented class message sends to Objective-C
methods.
Swift SVN r3370
This implementation is very lame, because we don't currently have a
way to detect (in Sema or SIL) where 'this' gets uniquely assigned,
and turn that assignment into initialization.
Also, I'm starting to hate the name 'allocating' constructor, because
it's the opposite of the Itanium C++'s notion of the allocating
constructor. Will think up a better name.
Swift SVN r3347
Tweak the import of Objective-C methods to build the proper FuncExpr
and tag the FuncDecl as an Objective-C method, along with a few other
tweaks, so calls to the imported Objective-C methods go through
objc_msgSend().
At this moment, this is aborting in the Objective-C runtime due to an
unrecognized selector. The issue does not appear related to the
importer.
Swift SVN r3255
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
Note that we have to be very careful not to introduce ambiguities
between the name of the getter and the name of the property, so we do
the following:
- "Informal" properties (where there is no @property) are not
mapped to Swift variables. The methods are just methods.
- An @property suppresses name lookup's ability to find
the getters and setters of that property, so having a "foo" property
eliminates the "foo" and "setFoo" methods.
- If an @property is added in a subclass, such that its getter or
setter come from a superclass, than that property cannot be mapped
to a Swift variable. Hopefully, this is rare.
As part of this, I had to make sure that Objective-C method overrides
were recorded as overrides in the Swift AST. The same will need to
happen for properties at some point.
Swift SVN r3245
