The introduction of += and -= default implementations on
AdditiveArithmetic introduces an ambiguity with the += and -=
implementations on SIMD (where Scalar: FloatingPoint). Break the
ambiguity by adding another set of definitions of += and -= on
AdditiveArithmetic & SIMD where Self.Scalar: FloatingPoint.
Fixes rdar://problem/55278156.
Returns `true` if `T.Type` is known to refer to a concrete type. The
implementation allows for the optimizer to specialize this at -O and
eliminate conditional code.
Includes `Swift._isConcrete<T>(T.Type) -> Bool` wrapper function.
It is causing bots to fail.
* Revert "The __has_include(<os/system_version.h>) branch here wasn't quite right, we'll just use the dlsym one for now"
This reverts commit f824922456.
* Revert "Remove stdlib and runtime dependencies on Foundation and CF"
This reverts commit 3fe46e3f16.
rdar://54709269
These were previously removed in SE-0246, so they weren't modified when Float80 was removed elsewhere on Android. Reverting SE-0246 on master triggers an Android break.
* Revert "Add availability information to the new Math function protocols (#24187)"
This reverts commit d2f695935f.
* Revert "SE-0246: Protocols and static functions (#23824)"
This reverts commit 57a4553832.
* Expected abi changes.
This improves code generation in -Onone mode. (UnsafeRawPointer.load/.storeBytes isn’t @_transparent and it doesn’t get specialized in unoptimized builds.)
AutoreleasingUnsafeMutablePointer is pointing to a +0 reference, but in its pointee property’s getter/setter implementations, it is loading the pointer into regular Unsafe[Mutable]Pointers. Those are assuming that the addressed memory contain a +1 reference, which can mislead the compiler into doing optimizations that aren’t valid.
Change the getter/setter implementations so that they use UnsafeRawPointer and load/store Unmanaged values instead. As long as Unmanaged.passUnretained(_:) and Unmanaged.takeUnretainedValue() do the right thing, then AutoreleasingUnsafeMutablePointer won’t have issues, either. (This boils down to ensuring that loading a strong reference out of an unmanaged(unsafe) value works correctly.)
* Remove doc comments from concrete floating-point types
... when they are already present on the protocol. I don't *think* that we need them anymore for xcode documentation purposes. There are reasonable arguments both ways on this:
1. when you're editing the concrete implementations, it's sometimes nice to have the doc comment right there.
2. but it needlessly repetitive, and introduces the opportunity for comments to get out of sync.
3. it also adds noise; it would be nice for information density if the implementation only had implementation notes.
* Add examples to documentation for FloatingPoint.isCanonical
In particular, document that subnormal encodings are treated as non-canonical zeros on platforms that flush to zero.
* Additional fixes by @xwu and @natecook1000 .
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
One additional tweak (setting the scalar-aligned bit on foreign indices) had to be made to avoid a performance regression for long non-ASCII foreign strings.
