The print abi changed so that there is no longer a way to print one item to a
stream without going through a vararg array. We call the print function in a
String initializer (e.g for string interpolation) incurring unnecessary
overhead. Use an internal specialized version of print instead.
rdar://22133281
Swift SVN r31000
- Add Strict/Defaulted Index types to StdlibUnittest
- Test whether a random access index calls its more efficient
customization by tracking successor calls.
- Fix the RandomAccessIndex.advancedBy(n, limit:) API by de-underscoring
the limit parameter
- Inline some internal transparent default implementations to their only
call site
- Attach _RandomAccessAmbiguity type to RandomAccessIndex
rdar://problem/22085119
Swift SVN r30979
The parse_stdlib tests choke on the constraints that were there previously,
so weaken the API to only work on intervals of the same type for now.
rdar://problem/22126470
Swift SVN r30977
There's still work left to do. In terms of next steps, there's still rdar://problem/22126141, which covers removing the 'workaround' overloads for print (that prevent bogus overload resolution failures), as well as providing a decent diagnostic when users invoke print with 'appendNewline'.
Swift SVN r30976
- 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