Adds in a special case grapheme break detection between two values
within scalar ranges where we have special knowledge. Any sub-0x300
scalars, except CR-LF, are guaranteed to have grapheme breaks between
them. We're reasonably confident this will not change in future
versions of Unicode. We might add more ranges in the future, but
should do so conservatively, anticipating future Unicode changes.
In these cases we can very quickly break, even for strings that have
mixed latin and emoji characters. In a ASCII string with a single
emoji in it, we traverse the string 2x faster forwards and 3x faster
in reverse. (Reverse is 3x faster as it involves some forwards
traversal inside of the index). For a string that's half Latin half
non-Latin, we're about 1.5x faster forwards and backwards.
* [stdlib] String : RangeReplaceableCollection & BidirectionalCollection
* Add source compatibility hack for Swift.max
* Add source compatibility hack for Swift.min
* Remove redundant conformance in benchmarks
* Fix stupid typo I thought I'd already pushed
* XFAIL testing now-redundant conformance
* XFAIL an IDE test for now
These tests included sources that are
based on Swift 3. They can be considered to be updated later to Swift 4, but it did not seem critical for what they were testing.
Eliminate the vestigial type `LazyFilterIndex`, which was
necessary pre-Swift-3 to allow the index to move. Swift 3's indexing
model means that the movement of indices is on the collection itself,
so we no longer need `LazyFilterIndex`: instead, the `Index` type of
the lazy filtered collection is simply the `Index` type of the base
collection, which is a nice convenience: it means you can take indices
from a lazy wrapper around a given collection C and use them with the
collection C (and, with care, vice-versa) without jumping through
extra hoops.
The goal here is to make the short demangling as short and readable as possible, also at the cost of omitting some information.
The assumption is that whenever the short demangling is displayed, there is a way for the user to also get the full demangled name if needed.
*) omit <where ...> because it does not give useful information anyway
Deserializer.deserialize<A where ...> () throws -> [A]
--> Deserializer.deserialize<A> () throws -> [A]
*) for multiple specialized functions only emit a single “specialized”
specialized specialized Constructible.create(A.Element) -> Constructible<A>
--> specialized Constructible.create(A.Element) -> Constructible<A>
*) Don’t print function argument types:
foo(Int, Double, named: Int)
--> foo(_:_:named:)
This is a trade-off, because it can lead to ambiguity if there are overloads with different types.
*) make contexts of closures, local functions, etc. more readable by using “<a> in <b>” syntax
This is also done for the full and not only for the simplified demangling.
Renderer.(renderInlines([Inline]) -> String).(closure #1)
--> closure #1 in Renderer.renderInlines
*) change spacing, so that it matches our coding style:
foo <A> (x : A)
--> foo<A>(x: A)
* [runtime] Fix some casts of _SwiftValue.
* Allow _SwiftValue to be cast to NSObject by yielding the box object itself.
* Failed casts from NSDictionary containing _SwiftValue should not crash.
SR-4306, rdar://31197066
These subtests were actually meant to test the raw buffer
type itself, not its slice type. So adding an `init(rebasing:)`
does what we want.
Now that the Collection tests are wired up, these test cases will be run on the
slice type automatically. No need to do it here.
Some build configurations seem to be unexpectedly crashing even
in "release" mode. I'm not sure yet why they're hitting an assert.
These sub-tests are affected:
["subscript.get.underflow", "subscript.get.overflow",
"subscript.set.underflow", "subscript.set.overflow",
"subscript.range.get.underflow", "subscript.range.get.overflow",
"subscript.range.set.underflow", "subscript.range.set.overflow"]
Allows converting a raw slice into a zero-based raw buffer,
which is a common operation on flat memory.
Add and update UnsafeRawBufferPointer unit tests.
