Fixes a general category (pun intended) of scalar-alignment bugs
surrounding exchanging non-scalar-aligned indices between views and
for slicing.
SE-0180 unifies the Index type of String and all its views and allows
non-scalar-aligned indices to be used across views. In order to
guarantee behavior, we often have to check and perform scalar
alignment. To speed up these checks, we allocate a bit denoting
known-to-be-aligned, so that the alignment check can skip the
load. The below shows what views need to check for alignment before
they can operate, and whether the indices they produce are aligned.
┌───────────────╥────────────────────┬──────────────────────────┐
│ View ║ Requires Alignment │ Produces Aligned Indices │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ Native UTF8 ║ no │ no │
├───────────────╫────────────────────┼──────────────────────────┤
│ Native UTF16 ║ yes │ no │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ Foreign UTF8 ║ yes │ no │
├───────────────╫────────────────────┼──────────────────────────┤
│ Foreign UTF16 ║ no │ no │
╞═══════════════╬════════════════════╪══════════════════════════╡
│ UnicodeScalar ║ yes │ yes │
├───────────────╫────────────────────┼──────────────────────────┤
│ Character ║ yes │ yes │
└───────────────╨────────────────────┴──────────────────────────┘
The "requires alignment" applies to any operation taking a
String.Index that's not defined entirely in terms of other operations
taking a String.Index. These include:
* index(after:)
* index(before:)
* subscript
* distance(from:to:) (since `to` is compared against directly)
* UTF16View._nativeGetOffset(for:)
ICU will return different results if we call with an offset into a
code unit buffer vs if we slice the buffer first and provide an offset
of zero. Slicing more closely models the semantics of SE-0180, so use
that.
Test case coming in subsequent commit enforcing index
scalar-alignment.
This was an ABI break, since it didn't make it into 5.0. Using _read here is unimportant, so we're just going to revert rather than try being fancy.
This reverts commit 04586e3916.
* Provide a default implementation of multipliedFullWidth
Previously, [U]Int64 fatalErrored on 32b platforms, which is obviously undesirable. This PR provides a default implementation on FixedWidthInteger, which is not ideally efficient for all types, but is correct, and gives the optimizer all the information that it needs to generate good code in the important case of Int64 arithmetic on 32b platforms. There's still some minor room for improvement, but we'll call that an optimizer bug now.
* Clarify comments somewhat, remove `merge` nested function
I was only using `merge` in one place, so making it a function seems unnecessary. Also got rid of some trucatingIfNeeded inits where the compiler is able to reason that no checks are needed anyway.
* Add some basic test coverage specifically for multipliedFullWidth
* Fix typo, further clarify bounds comments.
* Make new defaulted implementation @_aEIC so we don't need availability.
* [stdlib] Lemire’s nearly divisionless random int
Implementation of Daniel Lemire’s “Fast Random Integer Generation in Interval”
See https://arxiv.org/pdf/1805.10941.pdf
* [stdlib] Simpler, optimized expression
* [stdlib] O'Neill’s modulo optimization
See http://www.pcg-random.org/posts/bounded-rands.html#optimizing-modulo
* [stdlib] Remove modulo optimization
Swift, compared to C, seems unable to generate tightly fused instructions here for some reason (probably the division by zero check?)… removing.
* [stdlib] Keep OpenBSD debiasing method on 32-bit
systems until the https://bugs.swift.org/browse/SR-10910 is resolved.
* [stdlib] TODO FIXME SR-10912
Remove the old OpenBSD generation method, once 32-bit systems support multipliedFullWidth on UInt64.
For odd roots of negative values, we need to take the root of the *magnitude* of the number to avoid a NaN from the platform's implementation of `pow`, then restore the sign afterwards. We had the basic logic in place already, but were missing the step of taking the magnitude first. Also modified a test case to find this error.
* [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.
