This reverts commit r25678, which breaks the build:
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:117:34: error: integer literal overflows when stored into 'Int'
} else if utf8Bytes.count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:139:34: error: integer literal overflows when stored into 'Int'
} else if dataBytes.count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:160:24: error: integer literal overflows when stored into 'Int'
} else if count <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:189:31: error: integer literal overflows when stored into 'Int'
} else if mappingCount <= 0xffff_ffff {
^
/Users/dgregor/Projects/Apple/swift/stdlib/serialization/MsgPack.swift:235:29: error: integer literal overflows when stored into 'Int'
} else if data.count <= 0xffff_ffff {
^
Swift SVN r25693
The new modules are:
* SwiftUnstable -- assorted additions to the core standard library
(more algorithms etc.)
* SwiftUnstableDarwinExtras -- proposed additions to the Darwin overlay,
not yet reviewed by the Darwin team.
* SwiftUnstablePthreadExtras -- wrappers that make it possible to
use pthread in Swift (they work around the lack of block-based API in
pthread). In future these could be possibly folded into the Darwin
overlay as well.
These APIs are useful without StdlibUnittest for writing automation
tools in Swift. Just like SwiftExperimental, none of these modules are
exposed to extrenal users.
Also, since these new modules can be compiled with -sil-serialize-all
(unlike StdlibUnittest, where we can't apply the flag because of
compiler bugs), standard library tests that need to run optimized code
(like AtomicInt.swift) are *much* faster now.
Swift SVN r25679
The primary motivation for doing this is that NSCoding does not work
with struts and Swift containers. Making everything classes just to
satisfy NSCoding 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/Serialization.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.
These APIs will be used for writing automation tools in Swift. Just
like SwiftExperimental, this module is not exposed to extrenal users.
Swift SVN r25678
<rdar://problem/19803733> String#append(Character) is broken in Swift 1.2 (beta)
<rdar://problem/19809905> Swift 1.2: join does not work with Emoji strings
Swift SVN r25449
Generator observes a snapshot of the collection. Mutating the
collection should not have any effect on existing generators.
rdar://19726013
Swift SVN r25171
...into the validation suite. This is the wrong solution but at least
the bots will continue to run all the tests and we won't regress.
Swift SVN r24934
Addressing rdar://problem/19434979 will allow us to swizzle expected errors based on build configuration options,
but until I can push that change we should generalize a few of the expected errors in the FixedPointDiagnostics test,
and re-enable the test on ARM.
Swift SVN r24910
UTF16.{leadSurrogate,trailSurrogate} were converting intermediate
results to UInt16 too soon, causing a trap on U+20000 and higher.
rdar://19156359
Swift SVN r24678
Bitwise operations on Bool are redundant with other logic operations
that stdlib already provides. The only reason to have them was to avoid
branching in the short-circuiting && and ||.
rdar://19340952
Surprisingly, replacing & and | in the standard library with && and ||
brought performance improvements and no significant performance
regressions:
RecursiveOwnedParameter 1.14
SelectionSort 1.19
Swift SVN r24674