This is needed if we compile StdlibUnittest with -sil-serialize-all
So far I added the imports only in files which needed them. But this may change, depending on the optimizer (inlining).
Adding them in all files doesn't harm and avoids confusion if someone makes an unrelated change which would result in such a linker error.
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
getBytes still lacks the ability to take an optional buffer, but Ali
agrees that we can leave that off for this release in light of the fact
that we have lengthOfBytesUsingEncoding.
Swift SVN r31223
containsString and localizedCaseInsensitiveContainsString were
introduced in 10.10, release-noted, but never
documented (<rdar://22236574>), so we missed them.
Fixes <rdar://18776075> String.containsString doesn't work in Swift
Swift SVN r31152
- 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
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
