We can finally get rid of -sil-serialize-all when building the standard library! This option will be completely eliminated in the future commits.
Instead of serializing just everything as we did before, we now serialize only functions annotated with @_inlineable. This way we can selectively control what needs to be available to the clients. This is an important step towards building a resilient standard library.
While this is a huge change for the serialization of the stdlib, it should be virtually invisible to the clients. For example, there are no noticeable performance regressions on any of the benchmarks.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
This re-applies 361ab62454, reverted in
f50b1e73dc, after a /very/ long interval
where we decided if it was worth breaking people who've added these
conformances on their own. Since the workaround isn't too difficult---
use `#if swift(>=3.2)` to guard the extension introducing the
conformance---it was deemed acceptable.
https://bugs.swift.org/browse/SR-2388
and its transitive closure of overlay dependencies.
[utils]:find-overlay-deps-closure.sh: Add a bash script to find the
closure of all other overlays required by a target overlay.
For every struct type for which the frameworks provides an NSValue category for boxing and unboxing values of that type, provide an _ObjectiveCBridgeable conformance in the Swift overlay that bridges that struct to NSValue, allowing the structs to be used naturally with id-as-Any APIs and Cocoa container classes. This is mostly a matter of gyb-ing out boilerplate using `NSValue.init(bytes:objCType:)` to construct the instance, `NSValue.objCType` to check its type when casting, and `NSValue.getValue(_:)` to extract the unboxed value, though there are a number of special snowflake cases that need special accommodation:
- To maintain proper layering, CoreGraphics structs need to be bridged in the Foundation overlay.
- AVFoundation provides the NSValue boxing categories for structs owned by CoreMedia, but it does so using its own internal subclasses of NSValue, and these subclasses do not interop properly with the standard `NSValue` subclasses instantiated by Foundation. To do the right thing, we therefore have to let AVFoundation provide the bridging implementation for the CoreMedia types, and we have to use its category methods to do so.
- SceneKit provides NSValue categories to box and unbox SCNVector3, SCNVector4, and SCNMatrix4; however, the methods it provides do so in an unusual way. SCNVector3 and SCNVector4 are packaged into `CGRect`s and then the CGRect is boxed using `valueWithCGRect:`. SCNMatrix4 is copied into a CATransform3D, which is then boxed using `valueWithCATransform3D:` from CoreAnimation. To be consistent with what SceneKit does, use its category methods for these types as well, and when casting, check the type against the type encoding SceneKit uses rather than the type encoding of the expected type.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
https://bugs.swift.org/browse/SR-2388
Introduce typed accesses for the error types of AVFoundation,
CloudKit, Contacts, and CoreLocation. While here, fix the API notes
for the Contacts framework, which had an embarrassingly-wrong file
name ;)
The Clang attribute allows one to state that a particular enumeration
type describes an error, and associates it with a particular domain
constant. However, due to lack of API notes support, this attribute
wasn't actually getting used. Instead, we had a number of explicit
extensions to enum types to make them conform to the _BridgedNSError
protocol explicitly.
Now that we have API notes, use them to make these enums into error
enums with the appropriate domain, so that the Clang importer will
synthesize the _BridgedNSError conformances. Then, remove all of the
explicit conformances---and with them, the overlays for 12 frameworks.
There is a small fix to more eagerly consider these conformances as
"used" if an expression is formed with the error enum as a value
type. This better ensures that the conformances will be available at
runtime when needed.
This cleanup is needed to implement SE-0112 (NSError bridging),
although it is useful by itself.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
This inefficient call took up 8-9% of the compile time of Global ARC Opts when
compiling a release no-assert stdlib with a release compiler with assertions.
NFC.
<rdar://problem/22244924>
Swift SVN r31167
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
In iOS 9 and OS X 10.11 the old GameKit was effectively renamed GameCenter, while
the new GameKit is a sort of umbrella framework like Cocoa. We need to support
backwards deployment, though, so the GameCenter overlay links to GameKit.framework.
(This is essentially the same solution implemented for CoreImage moving out of
QuartzCore in r28449)
rdar://problem/21340738
Swift SVN r30322
CNErrorDomain is lacking proper availability annotations, and
explicitly linking with -weak_framework is not working reliably. For
now, just remove the overlay to solve rdar://problem/21030937. We'll
bring it back when rdar://problem/21032649 makes it into all of the
builds we care about.
Swift SVN r29003
The Cocoa error domain is comprised on error codes from Foundation,
CoreData, and AppKit. Rather than try to collect all of the error
codes into a single enum in Foundation, use a struct that conforms to
ErrorType. Part of rdar://problem/20536610.
Swift SVN r28755
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
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
The standard library has grown significantly, and we need a new
directory structure that clearly reflects the role of the APIs, and
allows future growth.
See stdlib/{public,internal,private}/README.txt for more information.
Swift SVN r25876
