These are triggering a bad compile-time regression for some expressions; that's a bug that should be fixed, but we don't know how to fix it yet, so we'll need to remove these in the short-term, and possibly spell them differently in the medium term.
* Additions to SIMD types.
- extension from 2 and 3-element vectors to 3- and 4-element vectors.
- the .one member
- swizzles via subscript-by-simd
- min/max/sum reductions
- min/max/clamp on vectors-of-comparable
- any and all
- Make permute subscript wrap on vector length, even for SIMD3 dictionaries. Also restore min/max to globals, rather than static functions.
* Revert "Merge pull request #23791 from compnerd/you-know-nothing-clang"
This reverts commit 5150981150, reversing
changes made to 8fc305c03e.
* Revert "Merge pull request #23780 from compnerd/math-is-terrible"
This reverts commit 2d7fedd25f, reversing
changes made to 0205150b8f.
* Revert "Merge pull request #23140 from stephentyrone/mafs"
This reverts commit 777750dc51, reversing
changes made to 0c8920e747.
The initializer was originally introduced without proper availability; in https://github.com/apple/swift/pull/23643, we fixed this by applying the `@_alwaysEmitIntoClient` attribute. However, this had the unfortunate side-effect that the symbol disappeared from `libswiftCore.dylib`, which somehow confuses some simulator builds.
Try to figure out what’s happening by replacing the third closure argument with an integer return value. This changes the mangled name of the bulk initializer, which should make it more obvious how/why these builds fail.
rdar://problem/49479386
This commit implements SE-0246, by adding conformance to Real to the Float, CGFloat, Double, and Float80 types, implemented either in terms of the system's C math library, existing standard library functionality, or LLVM intrinsics. It includes basic test coverage for these new functions, and deprecates and obsoletes *some* existing functionality in the Platform overlay. We still need to make a decision about how to handle the remaining "tgmath" functions, because obsoleting them is technically a source-breaking change (if users have unqualified names like "exp(1)", it's fine, but it would break users who have used qualified names like "Darwin.exp(1)".)
Fundamental decision to be made; should implementation hooks present like `Float.exp(_ x: Float) -> Float` or like `Float.Maths.exp(_ x: Float) -> Float`? Having the intermediate namespace to group them as in the second is definitely nicer, but it requires a little bit of extra machinery, and much more importantly, there doesn't seem to be any way to make access to the static `Maths` associatedtype transparent.
This can map straight to the LLVM copysign intrinsic for builtin types, which both gets us better codgen and lets the compiler plug this operation into other LLVM-level optimizations.
This adds new (availability-controlled) API to Unicode.Scalar,
exposing the scalar's UTF-8 code units as a random-access collection
similarly to how it currently exposes UTF-16 code units.
Tests added.
In Android ARMv7 there was no alias defined for CLongDouble, so
importing anything with long double was failing. Defining the alias
makes the test pass.
AAPCS64 defines long double as 128 bits, which is still unsupported by
Swift (SR-9072). Disable this particular test for Android and Linux in
AArch64 to not fail (but still test all the other tests).
[stdlib] Make unsafe array initializer public
This implements SE-0245. The public versions of this initializer call
into the existing, underscored version, which avoids the need for
availability constraints.
Magic symbols of the form $ld$install_name$os9.0$@rpath/libswiftCore.dylib tell the linker to use that install name when targeting that OS version. Use these symbols to specify an @rpath install name for all back-deployment libraries when targeting watchOS 2.0-5.1, iOS 7.0-12.1, and macOS 10.9-10.14.
rdar://problem/45027809
Bring formatting closer in line with the rest of the standard lib, remove "public" from extensions (moving it onto the contents defined therein). Restore Swift project headers that were apparently lost at some point.
Since a4e9109 (#17396), both the hashes and the equality of numeric
types inside of AnyHashable do not follow the rules that this part of
the comment was talking about.
I couldn't find an easy example that shows the same behaviour, so I
decided to remove the comment completely.
LLVM r355981 changed various intrinsic functions, including expect,
to require immediate arguments. Swift's _branchHint function has an
expected value that is passed in as an argument, so that it cannot
use LLVM's expect intrinsic. The good news is that _branchHint is only
ever used with immediate arguments, so we can just move the intrinsic
into _fastPath and _slowPath and use those instead of _branchHint.
As was noted in the documentation, the _fastPath and _slowPath names are
confusing but we have passed the point where we can simply rename them.
We could add new names but would still need to keep the old ones around
for binary compatibility, and it is not clear that it is worth the
trouble. I have removed that note from the documentation.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
1. Move discussion of `DBL_EPSILON` etc. onto `ulpOfOne` instead of `ulp`.
2. Add text explaining that `ulpOfOne` is a poor value to use for approximate comparison.
