`Sequence._copyContents(initializing:)` is the function relied on by
`UnsafeMutableBufferPointer` for performant initialization from Collections.
Until now, `Slice<Base: Collection>` has not had its own implementation,
and therefore fell back to the default version implemented on `Sequence`.
This implementation adds an attempted fast path, using
`withContiguousStorageIfAvailable`. If that fails, the `Sequence`
algorithm is used, as before.
This resolves https://bugs.swift.org/browse/SR-14491
- add a default implementation of MutableCollection’s
subscript(bounds: Range<_>) with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- add a conditionally-available subscript(bounds: Range<_>) -> Slice<Self>
only when Subsequence is Slice<Self>. This will supersede
the unconditional extension that provides the same signature.
- adds a default implementation of Collection’s subscript(bounds: Range<_>)
with the most general signature possible
- it is marked unavailable in order to prevent the
infinite recursion bug reported in SR-14848
- Collections whose SubSequence is Slice<Self> still get the proper default, as intended.
`_copyContents(initializing:)` is a core method of Sequence, and it is used surprisingly often to copy stuff out of sequences. Array’s internal types currently have explicit implementations of it that trap (to prevent a performance bug due to the default iterator-based implementation. This has proved a bad idea, as not all code paths that end up calling `_copyContents` have actually been expunged — so we replaced a performance bug with a catastrophic correctness bug. 😥
Rather than trying to play whack-a-mole with code paths that end up in `_copyContents`, replace the traps with (relatively) efficient implementations, based on the ancient `_copyContents(subRange:initializing)` methods that have already been there all this time.
This resolves https://bugs.swift.org/browse/SR-14663.
I expect specialization will make this fix deploy back to earlier OSes in most (but unfortunately not all) cases.
* Use the "nearly divisionless" algorithm on all targets.
We have multipliedFullWidth available everywhere now, so we don't need to carry around the old implementation on 32b targets.
Also adds a few more benchmarks for random number generation.
* Obscure the range boundaries for some of the new random value benchmarks.
When these are visible compile-time constants, the compiler is smart enough to evaluate the division in the "nearly divisionless" algorithm, which makes it completely divisionless. That's good, but it obscures what the runtime performance of the algorithm will be when the bounds are _not_ available as compile-time constants. Thus, for some of the newly-added benchmarks, we pass the upper bound through `identity` to hide it from the optimizer (this is imperfect, but it's the simplest tool we have).
We don't want to do this for all the tests for two reasons:
- compile-time constant bounds are a common case that should still be reflected in our testing
- we don't want to perturb existing benchmark results more than we have to.
There is still an incongruity between where `srcHigh` and `destHigh` are displayed in the diagram:
`srcHigh` is shown at the location it logically represents, not its true position which is one past that, whereas `destHigh` (as well as `bufferHigh`) is shown at its true position (past the end) not at the location it logically represents.
I am not sure if that is intentional.
This patch removes as much checked math as I was able to find from the
unsafe buffer pointers types. In particular, I removed two kinds of
checked math:
1. Checked math that was provably unable to trap due to prior operations
done in the same function, or in a function that must have been
called before the current one. For example, in
index(_:offsetBy:limitedBy:), when we do the final index addition we
have already validated that it must be in-bounds. Therefore, it
cannot overflow.
2. Checked math that can only fail if the user is misusing the indices.
As previously discussed with Karoy and Andrew, the unsafe raw buffer
types are not obligated to crash if you misuse their indices, they
are free to invoke undefined behaviour. In these cases, I added
defensive overflow checks in debug mode.
The result of this change should be reductions in code size in almost
all usage sites of the raw buffer types.
