- 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.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
This changed recently so that overflow and underflow consistently return signed
infinity or zero instead of nil. (Previously, overflow returned nil, underflow
returned zero.)
Among other benefits:
* The new behavior distinguishes malformed input (nil) from valid but out-of-range input.
* The new behavior preserves the sign of the input
* The new behavior is consistent with how floating-point parsing behaves in other langauges
Resolves rdar://76728925
An older Swift compiler failed to account for the witnesses in a
conformance with platform availability having their own availability,
which causes that compiler to reject the Swift module's .swiftinterface
file when it includes `AnyHashable` 's conformance to
`_HasCustomAnyHashableRepresentation`. Work around the issue by making
the one witness (`_toCustomAnyHashable`, which is trivial)
always-emit-into-client, so it does not need any availability.
Fixes rdar://76370138.
* [stdlib] Set.intersection iterate over smaller set
When intersecting two sets, it is beneficial to iterate over the smaller sized set of the two, and check membership on the other. This speeds up runtime dramatically for cases where the current set is significantly larger than the set you are intersecting against.
* Review comments - variable names, implicit swap
