Most of this is in updating the standard library, SDK overlays, and
piles of test cases to use the new names. No surprises here, although
this shows us some potential heuristic tweaks.
There is one substantive compiler change that needs to be factored out
involving synthesizing calls to copyWithZone()/copy(zone:). Aside from
that, there are four failing tests:
Swift :: ClangModules/objc_parse.swift
Swift :: Interpreter/SDK/Foundation_test.swift
Swift :: Interpreter/SDK/archiving_generic_swift_class.swift
Swift :: Interpreter/SDK/objc_currying.swift
due to two independent remaining compiler bugs:
* We're not getting partial ordering between NSCoder's
encode(AnyObject, forKey: String) and NSKeyedArchiver's version of
that method, and
* Dynamic lookup (into AnyObject) doesn't know how to find the new
names. We need the Swift name lookup tables enabled to address this.
Slice types that are RangeReplaceable (like ArraySlice) now slice
themselves in removeFirst(). Previously, these types were picking up
the wrong default implementation, and they were going through
replaceRange(), which caused all indices to be invalidated. The new
implementation preserves all indices.
rdar://22536664
Swift SVN r31918
...replacing it with the new, after passing API review!
* The lazy free function has become a property.
* Before we could extend protocols, we lacked a means for value types to
share implementations, and each new lazy algorithm had to be added to
each of up to four types: LazySequence, LazyForwardCollection,
LazyBidirectionalCollection, and LazyRandomAccessCollection. These
generic adapters hid the usual algorithms by defining their own
versions that returned new lazy generic adapters. Now users can extend
just one of two protocols to do the same thing: LazySequenceType or
LazyCollectionType.
* To avoid making the code duplication worse than it already was, the
generic adapters mentioned above were used to add the lazy generic
algorithms around simpler adapters such as MapSequence that just
provided the basic requirements of SequenceType by applying a
transformation to some base sequence, resulting in deeply nested
generic types as shown here. Now, MapSequence is an instance of
LazySequenceType (and is renamed LazyMapSequence), and thus transmits
laziness to its algorithms automatically.
* Documentation comments have been rewritten.
* The .array property was retired
* various renamings
* A bunch of Gyb files were retired.
Swift SVN r30902
See doc comments on MutableSlice for more information about what it is.
MutableSlice was one of the reasons to clarify and tighten index
invalidation rules. After that change, existing MinimalCollection
test types were performing checks that are too strict according to the
model. Existing algorithms and collections could provide them, but not
MutableSlice. This commit updates MinimalCollection types to perform
index invalidation checks that correspond to new rules.
Part of rdar://20722366. This commit adds the type, but does not wire
it up completely yet.
Swift SVN r30839
The type checker hits a recursion when checking the conformance to
CollectionType in UnsafeMutableBufferPointer, which requires
_withUnsafeMutableBufferPointerIfSupported, which mentions
UnsafeMutableBufferPointer. The easiest fix for now is to break the
recursion in the library.
Reverting this change is tracked by: <rdar://problem/21933004> Restore
the signature of _withUnsafeMutableBufferPointerIfSupported() that
mentions UnsafeMutableBufferPointer
Swift SVN r30838
Replace the Lazy-based implementations with open-coded implementations based on the _UnsafePartiallyInitializedContiguousArrayBuffer builder from the previous commit, so that we have control over the early-exit flow when an error interrupts the operation.
Swift SVN r30794
This makes the code for efficiently initializing array buffers in-place more accessible to the rest of the standard library, and should also provide a performance boost for _copySequenceToNativeArrayBuffer, which had been implemented as a naive append loop, by handling reallocating the buffer when necessary when initializing from a sequence that underestimates its count.
Swift SVN r30793
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
