String.Index has an encodedOffset-based initializer and computed
property that exists for serialization purposes. It was documented as
UTF-16 in the SE proposal introducing it, which was String's
underlying encoding at the time, but the dream of String even then was
to abstract away whatever encoding happend to be used.
Serialization needs an explicit encoding for serialized indices to
make sense: the offsets need to align with the view. With String
utilizing UTF-8 encoding for native contents in Swift 5, serialization
isn't necessarily the most efficient in UTF-16.
Furthermore, the majority of usage of encodedOffset in the wild is
buggy and operates under the assumption that a UTF-16 code unit was a
Swift Character, which isn't even valid if the String is known to be
all-ASCII (because CR-LF).
This change introduces a pair of semantics-preserving alternatives to
encodedOffset that explicitly call out the UTF-16 assumption. These
serve as a gentle off-ramp for current mis-uses of encodedOffset.
Compilation of code sample snippets was broken due to using the same
identifier as the `type` function itself to store its result resulting
in:
```swift
func printGenericInfo<T>(_ value: T) {
let type = type(of: value)
print("'\(value)' of type '\(type)'")
}
// error: repl.swift:2:16: error: variable used within its own initial
// value
// let type = type(of: value)
// ^
```
Result:
- Snippets are more copy&paste friendly.
- Resolves https://bugs.swift.org/browse/SR-9915
This fixes a major perform bug involving array initialization from any
contiguously stored collection. This is not a recent regression. This fix
results in a 10,000X speedup (that's 4 zeros) for this code path:
func initializeFromSlice(_ a: [Int]) -> [Int] {
return Array<Int>(a[...])
}
A benchmark is included.
This fix updates various initializers to handle incoming empty buffers
that happen to have a nil base. They should simply create another
buffer with nil base rather than crashing!
It is valid for an Unsafe[Raw]BufferPointer can have a nil base
address. This allows round-tripping with C code that takes a
pointer/length pair and uses `0` as the pointer value.
The original design wrongly assumed that we would use a sentinel value
for empty buffers and was never updated for or tested with the current
design.
Fixes <rdar://problem/47946984> Regression in Foundation.Data's
UnsafeBufferPointer constructor.
It is unfortunate that `Unsafe[Raw]BufferPointer._pointer` and
`baseAddress` are declared Optional. This leaves extra runtime checks
in the code in the most performance critical paths. Contrast this with
Array, which uses an sentinal pointer for the empty representation.
This forces us to use _unsafelyUnwrappedUnchecked whenever we just
want to dereference a non-empty buffer pointer.
Fixes SR-9809: swiftc appears to make some sub-optimal optimization choices
Without this change, SILGen will crash when compiling a use of the
derived protocol's requirement: it will instead attempt to use
the base protocol's requirement, but the code will have been
type-checked incorrectly for that.
This has a potential for source-compatibility impact if anyone's
using explicit override checking for their protocol requirements:
reasonable idioms like overriding a mutating requirement with a
non-mutating one will no longer count as an override. However,
this is arguably a bug-fix, because the current designed intent
of protocol override checking is to not allow any differences in
type, even "covariant" changes like making a mutating requirement
non-mutating. Moreover, we believe explicit override checking in
protocols is quite uncommon, so the overall compatibility impact
will be low.
This also has a potential for ABI impact whenever something that
was once an override becomes a non-override and thus requires a
new entry. It might require a contrived test case to demonstrate
that while using the derived entry, but it's quite possible to
imagine a situation where the derived entry is not used directly
but nonetheless has ABI impact.
Furthermore, as part of developing this patch (earlier versions of
which used stricter rules in places), I discovered a number of
places where the standard library was unintentionally introducing
a new requirement in a derived protocol when it intended only to
guide associated type deduction. Fixing that (as I have in this
patch) *definitely* has ABI impact.
* Make SIMD types codable. We're considering this a bugfix.
This is a very tiny ABI change, in that user-defined SIMD types compiled with an earlier version of 5.0 will be missing the necessary conformance to Codable. Discussed with Ben, and we're OK with this because we don't think there are such types yet, and it can be fixed with a recompile.
* Add basic tests
