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
...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
- Added CollectionType and SequenceType.swift.gyb
- Added Slice.swift.gyb
- Added a template file for shared lazy flatMap code between sequences
and collections
- Moved some test structs into the respective Check* files in
StdlibUnittest.
- Slice.swift.gyb is still too slow for Debug-Assert stdlib builds.
I've added a requirement to use the optimized standard library but
we should split this file out even further.
rdar://problem/22095015
Swift SVN r30894
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
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
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
- When we walk up through parent types of 'this', we also have to walk up
the parent contexts of 'gpContext', otherwise an assertion fires.
- getSuperclass() needs to map generic type parameters of the parent
type even if the superclass is not generic.
Swift SVN r30676
Validating the argument type might validate the enum decl in malformed (or
maybe even some valid?) code. We would call computeTwice() in this case,
leading to a crash.
Also clean up some test cases.
Swift SVN r30673
1. We have complex logic in stdlib/public/core/FixedPoint.swift.gyb that emits
or hides certain initializers on integer types based on the bit width
combination. We check that those APIs are indeed present or absent in cases we
expect.
All of [U]Int{8,16,32,64,} initializers, labelled and unlabelled.
(swift) UInt16(-10 as Int32)
<REPL Input>:1:1: error: integer overflows when converted from 'Int32' to 'UInt16'
UInt16(-10 as Int32)
(swift) UInt16(truncatingBitPattern: -10 as Int32)
// r3 : UInt16 = 65526
(swift) UInt16(truncatingBitPattern: -10 as Int16)
<REPL Input>:1:1: error: cannot invoke initializer for type 'UInt16' with an argument list of type '(truncatingBitPattern: Int16)'
UInt16(truncatingBitPattern: -10 as Int16)
<REPL Input>:1:1: note: overloads for 'UInt16' exist with these partially matching parameter lists: (Int16), (bitPattern: Int16)
A slight change in the type combination dramatically changes the available
overload set. You can’t check this with one or two tests and be confident that
every source/destination combination is correct.
2. We check that the APIs above are present or absent regardless of the target
platform so that the code is portable (for example, because Int64 -> Int is a
truncating operation on at least one platform, the corresponding “truncating”
initializer is available for portability on 64-bit platforms, even though it is
not actually truncating there.)
3. We rely on ambiguity in the overload set of “+“ and “-“ for certain
combinations of arguments to disallow mixed-sign arithmetic. Again, these
ambiguities rely on a tricky combination of protocols, associated types, the
way those associated types are defined by our integer types, and overload
resolution rules in the type checker.
4. The test also checks migration facilities for Word and UWord.
Swift SVN r30655
The protocol Self parameter is the last generic parameter in the signature,
not the first. While we don't allow protocols nested inside generic classes,
we would still crash in member type lookup from this.
Fixes <rdar://problem/21287703>.
Swift SVN r30635
When validateGenericFuncSignature() returns true, finalizeGenericParamList()
is never called. Name lookup, via PartialGenericTypeToArchetypeResolver would
return a dependent member type of the generic type parameter type, not an
archetype as expected in this case. This would later on lead to a crash in
ReplaceDependentTypes if the function body contained a reference to such a
member type.
Fix this by marking the GenericTypeParamDecls as invalid in this case, and
returning an ErrorType from PartialGenericTypeToArchetypeResolver if given
an invalid GenericTypeParamDecl.
While we're at it, there was an unused isInvalid local variable in
TypeCheckDecl::visitFuncDecl(). It was written to but never read. Replace
the writes with calls to setInvalid().
Fixes <rdar://problem/19620340>.
Swift SVN r30632
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
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
These tests trigger a bug in a lazy flatMap() that I will fix in a later
commit, but I want to commit tests separately to show that they pass
with the eager flatMap().
Swift SVN r30559
