Introduce a number of small overlays to bridge the NSError domains for
a number of frameworks into existing imported enums. This batch only
covers cases where there is an existing NS_ENUM describing the codes
for the domain, so we need only extend that enum to provide the
appropriate _BridgedNSError conformance.
This is the bulk of rdar://problem/20536610.
Swift SVN r28585
Fix the script to not wantonly drop availability annotations, and
update NSCocoError accordingly. Also drop in a reinterpret-casting
rawValue initializer, which matches what we get when importing enums
from C.
Swift SVN r28563
Bridging the Cocoa error domain requires us to gather constants from
Foundation, CoreData, and AppKit, then pulling those into a single
(_)NSCocoaError enum that conforms to
_ObjectiveCBridgeableErrorType.
Rather than using a table extracted from the appropriate Cocoa headers
and pushing that through gyb, just hardcode the resuting Swift code,
which is produced (manually) by an enumeration-parsing script. Thanks
to Dave for pointing out that I was holding gyb wrong.
... and apologies for the Perl.
Long term, we need a better solution here, but this will suffice for
the short term.
Swift SVN r28560
* Add --tvos option to swift-ios-test utility
* Mark failing tests appropriately
* Add support for TVOS predicates to stdlib unit tests
<rdar://problem/19854476> Swift: TV OS Testing Support
Swift SVN r28543
Expose constructors, ==, and other operators so they can be inlined down to
their underlying C struct operations. Add overlays for CG{Point,Rect,Size}Zero
and CGAffineTransformIdentity as well so we avoid having to load from the
opaque extern storage of the C constants. Recommits r28387 and addresses
rdar://problem/20888179, now that the previous commit worked around
rdar://problem/20902115.
Swift SVN r28527
Extend the NSCocoaError enum to cover all of the error codes in the
Cocoa error domain. Note that we need to do something awful for the
AppKit and CoreData errors, effectively redeclaring all of the
constants locally, because we cannot import AppKit and CoreData into
the Foundation overlay. It's not clear whether this blatant layering
violation will stand, but this at least improves coverage.
Also note that there are a number of warnings when building this code,
because some of the availability checks specify availability earlier
than our minimum deployment target. They're harmless and can be
cleaned up later.
Part of rdar://problem/20536610.
Swift SVN r28522
Now that we have lazy metadata accessors for classes and vtable thunking, we don't have any reason to prevent concrete subclasses of generic base classes. Wire up IRGen to lazily instantiate the superclass for concrete derived classes when their metadata is accessed, using a runtime function that installs all the necessary pointers and metadata and registers the fully-initialized class with the ObjC runtime.
Swift SVN r28520
The internal details of ErrorType are still being designed.
They should be underscored in the meantime to
indicate they are still evolving.
Implements rdar://problem/20927102.
Swift SVN r28500
This came out of today's language review meeting.
The intent is to match #available with the attribute
that describes availability.
This is a divergence from Objective-C.
Swift SVN r28484
We no longer allow extensions to provide generic parameters, and the
ability to parse the syntax
extension Array<String> { ... }
is causing confusion. Fixes rdar://problem/20873336.
Swift SVN r28468
On OS X 10.10 and earlier, CoreImage is a sub-framework of QuartzCore.
Users of CoreImage use "import QuartzCore" and link against QuartzCore.
On OS X 10.11 (and in the OS X 10.11 SDK), CoreImage is a top-level
framework. Users of CoreImage use "import CoreImage" and would link against
CoreImage. Of course, QuartzCore continues to re-export CoreImage's API.
When backwards-deploying, we need to continue linking against QuartzCore,
but still need to bring in the overlay if you import CoreImage. That's
what this patch does.
rdar://problem/20196610
Swift SVN r28449
