This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
* Restore elementwise min/max on SIMD, but as statics instead of free functions.
Having these as free functions causes expression too complex issues due to overload vis-a-vis min<Collection>. There are (at least) three plausible solutions:
1. Fix the typechecker. This is infeasable in the short term; or more precisely, we do not know how much work is involved.
2. Give these operations different names. Candidates discussed with core team include "pointwiseMin", "elementwiseMin", "lanewiseMin"; these all suffer from the flaw that when someone writes "min" in a SIMD context, they are essentially always looking for either the horizontal minimum (reduction) on a single vector or--more often--the lanewise minimum of two vectors (this operation). It would be odd to give the operation that people actually want the unnecessarily verbose name.
3. Make these operations static; this is, in effect, a different name, but it's one which frequently allows eliding the qualifier:
let x = v + .min(v, w)
This isn't perfect; you will still need to spell out SIMD4.min( ) fairly often, but that's more concise than any of the proposed alternatives, and at least allows elision some of the time. Also, if you squint, you can pretend that the "." prefix is like ".<" and ".&" and indicates lanewise operation.
This implements the protocols and static functions proposed in SE-0246, plus some initial test coverage. It also has some rough accompanying cleanup of tgmath. It does not include the globals (on scalars or SIMD types) nor does it deprecate much in tgmath.h.
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).
