- Remove free Swift functions for advance and distance and replace
them with protocol extension methods:
- advancedBy(n)
- advancedBy(n, limit:)
- distanceTo(end)
- Modernize the Index tests
- Use StdlibUnittest
- Test for custom implementation dispatch
Perf impact: No significant changes reported in the
Swift Performance Measurement Tool.
rdar://problem/22085119
Swift SVN r30958
(or in 'randomShuffle')
This violates our inout aliasing rules, and can cause a crash in certain
situations.
To try to prevent this in the future I've added a debugPrecondition check
to 'swap' that checks addresses. This will only catch inout violations
where neither argument uses writeback, and might some day be optimized
away. Right now, though, it does seem to catch some simple violations
(though not the one in the Radar), so hopefully it will at least help keep
us from introducing new problems.
rdar://problem/21780567
Swift SVN r30956
...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
It reads more naturally to keep all the text arguments together.
One day maybe this will be a method on OutputStream, but probably not as
long as String conforms to it :-)
Swift SVN r30864
ArraySlice indices now map directly onto the collection it is slicing
and maintains that mapping even after mutations.
Before:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 0..<5
s[0] = 111
s // [111, 6, 7, 8, 9]
s.removeFirst()
s.indices // 1..<5
After:
var a = Array(0..<10)
var s = a[5..<10]
s.indices // 5..<10
s[5] = 99
s // [99, 6, 7, 8, 9]
s.removeFirst()
s.indices // 6..<10
- Refactor some of the internals of the buffer types to make it easier
to read and understand.
- Add Array, ArraySlice, and ContiguousArray to the test suite at the
RangeReplaceable test entry points, subjecting them to the same tests
as all of our collections.
- Update existing test expectations for the indexing changes.
rdar://problem/21866825
Swift SVN r30840
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
Including:
- forEach
- split
- Optional flatMap
- minElement
- maxElement
- startsWith
- elementsEqual
- lexicographicalCompare
- contains
- reduce
Still not touching 'map', 'filter', 'flatMap', or 'sort', which need various levels of rearchitecting to fix.
Swift SVN r30792
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
This version of the patch updates some protocol customization implementations that I missed the first time around, and includes the tests I forgot to add in the previous iteration.
Swift SVN r30790
For Dictionary, that's a (KeyType, ValueType) pair. For Set, that's just
the set element type. This is more consistent with the removeAtIndex on
RangeReplaceableCollectionType (which Dictionary and Set don't conform to).
rdar://problem/20299881
Swift SVN r30696
An index of a FlattenCollection is composed of two: an index to the
current chunk and an index within that chunk. So you take the
startIndex, and advance it to the second chunk; call the result idx1.
You take startIndex again, and advance it the same number of steps; call
the result idx2:
let idx1 = flatMapCollection.startIndex.advancedBy(10)
let idx2 = flatMapCollection.startIndex.advancedBy(10)
idx1 and idx2 have to compare equal according to collection and index
axioms. But this can't be cheaply implemented. Every index contains an
index into the inner collection. So indices into two collections with
the same elements have to compare equal even though the collections
don't have any common history, they were merely created using the same
sequence of steps.
What currently happens is that you get random results depending on the
underlying collection kind.
rdar://21989896
Swift SVN r30617
FlattenCollection used to evaluate the closure three times per element.
That's acceptable from the technical standpoint, given its lazy
semantics, but not acceptable in practice. This commit fixes it to only
evaluate it two times when it is converted into an array.
This commit also improves tests. The new checks used to fail before the
standard library was fixed.
But there are larger issues with FlattenCollection -- it does not model
CollectionType properly. See next commit.
Swift SVN r30616
Otherwise, we end up with declarations with public access that do not
have public 'self' types. These declarations can then be used by other
modules, which may end up trying to access non-external symbols.
This closes a loophole currently in use by the standard library, so
the '_prext_ReverseIndexType' and '_ReverseCollectionType' protocols
become public for now. In order to keep the API impact minimized,
extensions involving these protocols now extend them directly, so that
all of the "private" stuff shows up in one place in the generated
interface. This is not a long-term solution, but it's no worse than
the rest of the underscore rules in the standard library.
rdar://problem/21380336 tracks relaxing access restrictions for protocol
conformances when the witnesses come from a different type, like a
protocol extension. This requires some SILGen work to do correctly.
Finishes rdar://problem/21559986
Swift SVN r30612
This covers:
- Lifetime-extending wrappers, like withExtendedLifetime, withCString, and withUnsafe*Pointer
- 'map' and friends on Optional
- 'indexOf'
A few APIs I haven't gotten to yet in this first pass:
- Autoclosure APIs, like assert, &&, etc.
- the 'isOrderedBefore' predicate for sorting APIs. The sorting implementation does some microoptimizations with 'inout' closures that violate rethrows checking.
- Strict 'map', 'filter', and friends on CollectionType. These need some plumbing in Lazy to be able to thread a Result-forming transformation through.
Swift SVN r30597
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
They pass various operations through to the base
collection (e.g. LazyMapCollection's .count) and thereby avoid taking
the potentially-slower path through the default implementation.
Swift SVN r30554
