* Update example code to compile with Swift 5.0/5.1
Took inspiration from Filter.swift as to modern syntax to use, though didn't convert `private` properties to `internal`.
* simplify example code as requested
Removed private scope on properties to enable synthesized initializers; removed previously added explicit initializers; add necessary parameter label.
* Update stdlib/public/core/LazySequence.swift
remove ill advised usability change
Co-Authored-By: Xiaodi Wu <xiaodi.wu@gmail.com>
* Update stdlib/public/core/LazySequence.swift
Co-Authored-By: Xiaodi Wu <xiaodi.wu@gmail.com>
the builtin.globalStringTablePointer to the new OSLog overlay.
Modify the new OSLog implementation to use this SPI instead of
`withCString` to pass the (compiler-generated) format string to
the C os_log_impl ABI.
Move the OSLogOptimization pass before constant propagation in
the pass pipeline so that the SPI and the builtin it uses can be
folded to a string_literal instruction.
Update OSLogTests to work with the changes in the implementation.
Since scalar-alignment is set in inlinable code, switch the alignment
bit to one of the previously-reserved bits rather than a grapheme
cache bit. Setting a grapheme cache bit in inlinable would break
backward deployment, as older versions would interpret it as a cached
value.
Also adjust the name to "scalar-aligned", which is clearer, and
removed assertion (which should be a real precondition).
There are situations where you want to build against a libc that is out
of tree or that is not the system libc (Or for cross build scenarios).
This is a change for passing the -sdk and include paths for things like
this.
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
