Update tests to match, and rewrite SwiftPrivatePthreadExtras to take advantage of native C function pointer support instead of hacking it up through a stub C++ library.
Swift SVN r27598
and cleanup.
I changes cases that had a non-trivial "then" body but a trivial else. Most of the cases in
the stdlib have a trivial "then" clause, so I didn't change them.
Swift SVN r27567
Now we initialize the array buffer from sequences using unsafe pointer
arithmetic, which avoids extra retain/release traffic. But since the
size of the sequence is not known in advance, we only initialize as much
as underestimateCount() promises, and fall back to the slow approach for
the tail. Nevertheless, for collections, where the size is known
precisely, this technique is suboptimal only by one branch.
rdar://20530390
Swift SVN r27380
Atomically initialize and load the NSError bridging fields within an ErrorType box so that we do the right thing when two threads concurrently coerce the box to NSError.
Swift SVN r26996
These should all apply to any Darwin platform, and the current behaviour
was breaking cross-compilation.
Introduces a SWIFT_DARWIN_VARIANTS pattern, to be used as follows:
if(SWIFT_HOST_VARIANT MATCHES "${SWIFT_DARWIN_VARIANTS}")
Also fix one place where I checked the CMAKE_SYSTEM_NAME instead of the
host variant that I recently introduced. I haven't attempted to find
the rest of the places we're doing this though.
Swift SVN r26554
We have an SPI between the Swift compiler and Foundation based on the
SWIFT_SDK_OVERLAY_FOUNDATION_EPOCH preprocessor macro that allows us to
request the new API. rdar://20270080 tracks removing it.
Swift SVN r26475
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
This changes 'if let' conditions to take general refutable patterns, instead of
taking a irrefutable pattern and implicitly matching against an optional.
Where before you might have written:
if let x = foo() {
you now need to write:
if let x? = foo() {
The upshot of this is that you can write anything in an 'if let' that you can
write in a 'case let' in a switch statement, which is pretty general.
To aid with migration, this special cases certain really common patterns like
the above (and any other irrefutable cases, like "if let (a,b) = foo()", and
tells you where to insert the ?. It also special cases type annotations like
"if let x : AnyObject = " since they are no longer allowed.
For transitional purposes, I have intentionally downgraded the most common
diagnostic into a warning instead of an error. This means that you'll get:
t.swift:26:10: warning: condition requires a refutable pattern match; did you mean to match an optional?
if let a = f() {
^
?
I think this is important to stage in, because this is a pretty significant
source breaking change and not everyone internally may want to deal with it
at the same time. I filed 20166013 to remember to upgrade this to an error.
In addition to being a nice user feature, this is a nice cleanup of the guts
of the compiler, since it eliminates the "isConditional()" bit from
PatternBindingDecl, along with the special case logic in the compiler to handle
it (which variously added and removed Optional around these things).
Swift SVN r26150
These APIs will be used for writing automation tools in Swift. Just
like other private APIs, this module is not exposed to extrenal users.
The primary motivation for doing instead of using NSCoder this is that
NSCoder does not work with structs and Swift containers. Using classes
for everything just to satisfy NSCoder forces unnatural code.
This API requires two times (!) less boilerplate than NSCoding, since
the same method is used for serialization and deserialization. This API
is also more type-safe, it does not require the user to write 'as' type
casts, unlike NSCoding.
Please take a look at
validation-test/stdlib/SwiftPrivateSerialization.swift to see the
intended use pattern.
The performance of the underlying implementation is already decent, and
there's a lot of room for improvement.
This is a re-commit of r25678, with a fix for 32-bit platforms.
Swift SVN r25877
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
