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
This extension (introduced in https://github.com/apple/swift/pull/35264) was placed in a file location where it wasn’t correctly guarded against mentioning Float16 on macOS/x86_64, so the generated .swiftinterface file included a reference to an unavailable declaration. (The dummy stand-in Float16 type that we currently use on Intel macOS.)
Moving the declaration out of the “AnyHashable” section and into a file region that’s more suitable for it (i.e., enclosed in `#if !((os(macOS) || targetEnvironment(macCatalyst)) && arch(x86_64))`) resolves the issue.
rdar://76025365
It saved some boilerplate, but if it doesn't get inline (as in debug builds), Swift doesn't know how to legalize the type at the call boundary, and we crash.
* Replace lhs/rhs with a/b for clarity of documentation and to match concrete ops.
* Concretize additional SIMDMask operations:
.&=, .|=, .^=, .==, .!=
Also reflect documentation changes back to generic implementations.
Adds concrete overloads of the following SIMD operations:
- Comparisons: .==, .!=, .<, .<=, .>, .>=
- Logical operations on masks: .!, .&, .^, .|
- Integer arithmetic: &+, &-, &, &+=, &-=, &=
This makes some simple benchmarks 10-100x faster, which is basically a no-brainer, while staying away from the most heavily used operators, so hopefully doesn't impact compilation performance too badly.
* Casting from AnyHashable to AnyHashable should never create another wrapper
This adds a conformance for _HasCustomAnyHashableRepresentation to
AnyHashable that simply returns self. This ensures that anytime
you try to create a new AnyHashable wrapper for an existing
AnyHashable, you just get back the original.
Resolves rdar://75180619
* Move the `Struct AnyHashable` change to `without-asserts` list
As suggested by @lorentey
* [stdlib][SR-13883] Avoid advancing past representable bounds when striding.
* [stdlib] Expand a test and add a comment to ensure correct floating-point stride bounds checking.
* [stdlib][NFC] Clarify a comment in a test.
* [stdlib][NFC] Adjust copyright notices, clarify comments, delete '-swift-version=3' for tests.
* [stdlib] Add implementations for fixed-width integer strides for performance.
* [stdlib] Document `Strideable._step` and modify overflow checking behavior of `Stride*Iterator`.
* [stdlib] Address reviewer comments, postpone documentation changes
* [stdlib][NFC] Update documentation for '_step(after:from:by:)'
* [stdlib][NFC] Use 'nil' instead of an arbitrary value for integer striding '_step' index
For this special case we copied the objects out of the cocoa array without retaining them.
This lead to a double-free crash.
Unfortunately I could not come up with an isolated test case.
rdar://74624065