Leftover bits of SE-0055. Now that pointer nullability is reflected
in the type system, we can properly import throwing methods with
non-object pointer return types.
Note that Swift still won't let you declare them. That's coming next.
SR-1129 tracks an issue in which the linking step fails if a base class,
defined in an imported module with a `public private(set) var`, is subclassed
by another module. This adds a test that XFAILs on Linux. The test
passed on OS X.
This issue is currently forcing swift-corelibs-xctest and
swift-corelibs-foundation to mark several privately-used variables as
`public`.
For the most part this was just "check isInstanceProperty"; the one feature not yet implemented
is the emission of ObjC metadata for class properties.
rdar://problem/16830785
class B<T> : NSFoo {}
class A : B<Int> {}
IRGen computes the ivar layout starting from offset zero, since
the size of the 'NSFoo' is unknown and we rely on the Objective-C
runtime to slide the ivar offsets.
The instantiated metadata for B<Int> would contain a field offset
vector with the correct offsets, because of how
swift_initClassMetadata_UniversalStrategy() works.
However, A's metadata is emitted statically, and this includes a
copy of the field offset vector from the superclass. A's metadata
was initialized by swift_initializeSuperclass(), which did not
copy the field offset vector over from A<Int>. And since the
Objective-C runtime only slides the immediate ivars of a class,
the field offsets corresponding to A<Int>'s fields in B's type
metadata were never slid, resulting in problems when an instance
of B was passed to a function operating on an A<T> generically.
Fixes <rdar://problem/23200051>.
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
These tests emulate deploying back to an older OS where newer APIs are not
available by linking to an Objective-C framework where APIs have been
annotated to only be available in the far future and then moving the famework
aside so that it can't be found at run time.
These tests include some basics (global variables and classes), but the focus
is on Objective-C protocols to validate the change allowing types to
conform to protocols less available than the types themselves.
Swift SVN r30005
correct preconditions for ObjC layout, and write the
computed offsets back to global ivar offset variables
when present.
Swift will use the global variables for accesses to
ivars when it can show that their offsets are
non-dependent.
Fixes a major problem with generic subclasses of ObjC
classes whose dynamic layout does not match the layout
in their @interface.
rdar://19583881
Swift SVN r25536
Previously we were only getting system search paths (via dlopen), so you
couldn't ever load system frameworks.
This is the compiler side of <rdar://problem/17629517>, which is
unfortunately not the useful part.
Swift SVN r19831
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
...unless the functions are declared [transparent], or if we're in an
immediate mode (in which case we won't get a separate chance to link
against the imported TUs).
This is an optimization that will matter more when we start dealing with
Xcode projects with many cross-file dependencies, especially if we have
some kind of implicit import of the other source files in the project.
In the future, we may want to parse more function bodies for the purpose
of inlining, not just the transparent ones, but we weren't taking
advantage of that now, so it's not a regression. (We're still not taking
advantage of it even for [transparent] functions.)
Swift SVN r7698
