* [InterfaceGen] Only print 'mutating' and 'nonmutating' on accessors
* Add SILGen test for usage of dynamic accessors in and out of interfaces
* Add -enable-objc-interop to dynamic_accessors test
The information about whether a variable/property is initialized is lost in the
public interface, but is, unfortunately, required because it results in a symbol
for the initializer (if a class/struct `init` is inlined, it will call
initializers for properties that it doesn't initialize itself). This is
important to preserve for TBD file generation.
Using an attribute rather than just a bit on the VarDecl means this fits into
the scheme for module interfaces: textual/valid Swift.
A bunch of tests that technically require Objective-C interop were
not labeled as such, and worked in the absence of Objective-C interop
due to bugs in the type checker.
Instead, propagate the decision from the associated storage decl (var
or subscript), using the mechanisms that are already in place.
rdar://problem/29741743
Even if the method is marked override we need to emit an objective C method
call.
There is no v-table guarantee because of the override keyword. The base class
method might be in an objective c class.
rdar://27389992
These classes don't show up well in generated headers (rdar://problem/20855568),
can't actually be allocated from Objective-C (rdar://problem/17184317), and
make the story of "what is exposed to Objective-C" more complicated. Better
to just disallow them.
All classes are still "id-compatible" in that they can be converted to
AnyObject and passed to Objective-C, they secretly implement NSObjectProtocol
(via our SwiftObject root class), and their members can still be individually
exposed to Objective-C.
The frontend flag -disable-objc-attr-requires-foundation-module will disable
this requirement as well, which is still necessary for both the standard
library and a variety of tests I didn't feel like transforming.
Swift SVN r29760
Always perform override checking based on the Swift type
signatures, rather than alternately relying on the Objective-C
selectors. This ensures that we get consistent override behavior for
@objc vs. non-@objc declarations throughout, and we separately make
sure that the Objective-C names line up.
This also allows us to inherit @objc'ness correctly (which didn't
quite work before), including inferring the Objective-C selector/name
(the actual subject of rdar://problem/18998564).
Fixes rdar://problem/18998564.
Swift SVN r25392
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
When we introduce a method into a class extension (such that it does
not override any other method), we cannot add a vtable slot for that
method and therefore cannot perform dynamic dispatch on it without
going through objc_msgSend. To work around this bug
(<rdar://problem/17950064>), infer 'dynamic' for these cases, which
pushes us through objc_msgSend to get the appropriate semantics.
Note that we do *not* want this to interfere with inference of
'final', which means allowing 'final' inference to delete the
'dynamic' we introduce with the above.
Swift SVN r21135
