This is a follow-up fix for making struct constructors inline(__always) in
155db0a4bd: Let Character literals, which fit into 64 bits, be folded into a single integer constant.
and
d8f1caf4a6: Inline all the new low-level bits
If we decide that this structs should not have fixed layout we must re-evaluate the performance difference of not being able to inline
the struct constructors.
This adds a fast path for single-code-unit Character
construction. Rather than use the general purpose String based
initializer (which then repeats grapheme breaking to ensure a trap,
amongst other inefficiencies), just make the Character from the single
unicode scalar value directly.
This also speeds up simple iteration of BMP strings when the optimizer
is unable to eliminate the subscript. Around 2x for ASCII, and around
20% for BMP UTF16.
This is done by ensuring that the corresponding Character constructor is inlined. llvm will do the constant folding.
Also add a test which checks this.
It makes character literals much faster (3x improvement for the CharacterLiteralsSmall benchmark)
And it removes _a lot_ of redundant code (~80% for the CharacterLiteralsSmall benchmark)
I had optimistically written the code here optimistically hoping #7837 would land in time for me to merge, but that didn't happen, so adjust some things to match the current 12-byte object header size on 32-bit, and introduce some ABI constants for the expected 32- and 64-bit object header sizes we can assert against so that we have some robustness when it eventually changes again. Implements rdar://problem/31768303.
The underlying type's ordering may not be appropriate for the wrapped
type (think an ordered list whose underlying type is NSString).
Frameworks can always add a Comparable conformance explicitly.
We squeak out of this being a source-breaking change by virtue of
never having released a working version of it. Rintaro fixed the
ambiguity problems back in f11b74176b, but that was after the last
rebranch for Swift 3.1.
rdar://problem/30166538
Now that `String` conforms to the `BidirectionalCollection` protocol, in
the expression `let x = [""].joined()` the best matching overload for
`joined` is no longer the one returning `String`.
Fixes: <rdar://problem/31899440>
This eliminates the counting step for a lazy filtered collection
when converting it into an array by treating the collection
as a sequence when copying elements. FlattenCollections already
have this behavior. (SR-4164)
The box types were previously fileprivate because they lived in
the Foundation overlay. As part of the Swift stdlib, though, they need
to be internal so they can be linked against.
