* [docs] Update `trailingZeroBitCount` documentation
Document the required behavior for `trailingZeroBitCount` when the value is zero. Namely, in that scenario, `trailingZeroBitCount` should be equal to `bitWidth`.
* [docs] Address reviewer comments on `trailingZeroBitCount` docs
`String.+=` function to `String.append` function, and use a new
semantics attribute for String.+=.
Teach the constant evaluator about `String.Append` instead of `String.+=`.
* Add availability information to the new Math function protocols
The protocols ElementaryFunctions, RealFunctions, and Real are new in Swift 5.1 and accordingly need to have availability attached to them for platforms that are ABI-stable. The actual implementation hooks (static functions) are unconditionally defined on scalar types and marked @_alwaysEmitIntoClient, so they are available even when targeting older library versions, but the protocols themselves, and anything defined in terms of them (the global functions and the SIMD extensions) is only available when targeting library versions that have the new protocols.
* Additionally provide concrete implementations of signGamma for each stdlib-builtin floating-point type.
* Remove Real[Functions] protocols pending re-review
Temporarily pull these back so we can make minor tweaks to the design and get a re-review on SE.
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)".)
