This was ... returning the same thing as the == operator.
Also, integrate the CoreMedia overlay tests from
rdar://problem/20926198, which caught this problem, and port it
to StdlibUnittest.
Swift SVN r32484
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
Revert "Add test cases to exercise the native String vs cocoa buffer String path."
Revert "stdlib: Add back a test I removed"
Revert "stdlib: Fix hasPrefix,hasSuffix tests"
Revert "stdlib: Add documentation for the cached ascii collation tables"
This reverts commit 31493, 31492, 31491, 31490, 31489.
There are linking errors in SwiftExternalProjects (we probably have to link
against libicucore somewhere).
Swift SVN r31543
Reapply of 31474 with a fix in _compareCocoaBuffer to use the bufferSizeRhs
variable instead of bufferSizeLhs for the right hand side buffer.
We no longer create intermediate NSString copies to compare and hash swift
Strings. Instead we call directly into the ICU library.
I measured a 1.2 to 2x improvement on dictionary benchmarks as a result of this.
The SuperChars benchmark is also about 1.2x faster because of this.
Pure ASCII comparison has gotten a little bit slower (20% on a pure comparison
micro-benchmark) because we no longer do a memcmp. Doing a memcmp on ASCII is
not the same as the default unicode collation. Instead we have to a string scan.
The default unicode collation does not order like ASCII does and ignores
characters (for example the \0 character).
rdar://18992510
Swift SVN r31489
Revert "stdlib: Add back a test I removed"
Revert "Add test cases to exercise the native String vs cocoa buffer String path."
Revert "stdlib: Move the darwin String implementation over to use the ICU library."
This reverts commit r31477, r31476, r31475, r31474.
Commit r31474 broke the ASAN build.
Swift SVN r31488
We no longer create intermediate NSString copies to compare and hash swift
Strings. Instead we call directly into the ICU library.
I measured a 1.2 to 2x improvement on dictionary benchmarks as a result of this.
The SuperChars benchmark is also about 1.2x faster because of this.
Pure ASCII comparison has gotten a little bit slower (20% on a pure comparison
micro-benchmark) because we no longer do a memcmp. Doing a memcmp on ASCII is
not the same as the default unicode collation. Instead we have to a string scan.
The default unicode collation does not order like ASCII does and ignores
characters (for example the \0 character).
rdar://18992510
Swift SVN r31474
Some characters are not considered when comparing strings. Hashing in the length
would cause a difference of hash values in equal strings.
Swift SVN r31468
the regressions that r31105 introduced in the validation tests, as well as fixing a number
of other validation tests as well.
Introduce a new UnresolvedType to the type system, and have CSDiags start to use it
as a way to get more type information out of incorrect subexpressions. UnresolvedType
generally just propagates around the type system like a type variable:
- it magically conforms to all protocols
- it CSGens as an unconstrained type variable.
- it ASTPrints as _, just like a type variable.
The major difference is that UnresolvedType can be used outside the context of a
ConstraintSystem, which is useful for CSGen since it sets up several of them to
diagnose subexpressions w.r.t. their types.
For now, our use of this is extremely limited: when a closureexpr has no contextual
type available and its parameters are invalid, we wipe them out with UnresolvedType
(instead of the previous nulltype dance) to get ambiguities later on.
We also introduce a new FreeTypeVariableBinding::UnresolvedType approach for
constraint solving (and use this only in one place in CSDiags so far, to resolve
the callee of a CallExpr) which solves a system and rewrites any leftover type
variables as UnresolvedTypes. This allows us to get more precise information out,
for example, diagnosing:
func r22162441(lines: [String]) {
lines.map { line in line.fooBar() }
}
with: value of type 'String' has no member 'fooBar'
instead of: type of expression is ambiguous without more context
This improves a number of other diagnostics as well, but is just the infrastructural
stepping stone for greater things.
Swift SVN r31130
- 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
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
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
