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
* [stdlib] Deprecate MutableCollection._withUnsafeMutableBufferPointerIfSupported
In Swift 5.0, [SE-0237] introduced the public `MutableCollection.withContiguousMutableStorageIfAvailable` method. It’s time we migrated off the old, underscored variant and deprecated it.
The default `MutableCollection.sort` and `.partition(by:)` implementations are currently calling this hidden method rather than the documented interface, preventing custom Collection implementations from achieving good performance, even if they have contiguous storage.
[SE-0237]: https://github.com/apple/swift-evolution/blob/master/proposals/0237-contiguous-collection.md
* [test] Update tests for stdlib behavior changes
* Update stdlib/private/StdlibCollectionUnittest/CheckMutableCollectionType.swift
Co-authored-by: Nate Cook <natecook@apple.com>
* Update stdlib/private/StdlibCollectionUnittest/CheckMutableCollectionType.swift
Co-authored-by: Nate Cook <natecook@apple.com>
* Apply suggestions from code review
Co-authored-by: Nate Cook <natecook@apple.com>
* [test] LoggingMutableCollection: Fix logging targets
* [stdlib] Fix warning by restoring original workaround
Co-authored-by: Nate Cook <natecook@apple.com>
Array’s _copyContents implementation traps if given too small a buffer. This prevents Sequence._copyContents from being used to speed up copying data into discontiguous memory. (We have to require a Collection conformance and run _copyContents on slices instead).
Document the underlying requirement.
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
There's nothing useful to say about the type of .zero -- it's
constrained by the protocol to Self, so you don't have any choice what
it is when conforming to AdditiveArithmetic.
Fixes <rdar://problem/72592923> (SR-13983).
Because the attribute is part of the declaration, putting a doc comment
between the attribute and "public" ends up with the comment in the
middle of the declaration. This results in SourceKit skipping over the
comment, and the docs not being shown.
Fixes <rdar://problem/58716408>.
The default `partition(by:)` implementation cannot currently be specialized, which makes it ~64-100x slower than it could be for common cases. (E.g., `Array<Int>.partition(by: { $0 >= foo})` is slower than `.sort()` by a factor of 2-32.)
Make the implementation inlinable.
Even though Float16 is unavailable on macOS, the type metadata can
still be referenced, for example from another unavailable declaration.
Make sure it has the correct OS version annotation so that it can be
weak linked.
Part of <rdar://problem/72151067>.
Call through to _swift_modifyAtReferenceWritableKeyPath_impl in that case. This fixes an assertion failure (or worse) when upcasting a ReferenceWritableKeyPath and then using subscript(keyPath:) to modify a value with it.
rdar://74191390
