https://github.com/swiftlang/swift/pull/72612 can be reverted because it is no
longer necessary for the interface of the stdlib to be compatible with
compilers without `$TypedThrows` support.
Functions that are used in public `@inlinable` function bodies can't be marked
`@_spi` nor can they be made obsolete. Also, they must retain `rethrows` so
that use of these entry points from other `rethrows` functions is accepted.
Builds on https://github.com/apple/swift/pull/72365. Once we no longer have to
support pre-`$TypedThrows` compilers, all of this can be reverted.
Part of rdar://125138945
This isn't a "complete" port of the standard library for embedded Swift, but
something that should serve as a starting point for further iterations on the
stdlib.
- General CMake logic for building a library as ".swiftmodule only" (ONLY_SWIFTMODULE).
- CMake logic in stdlib/public/core/CMakeLists.txt to start building the embedded stdlib for a handful of hardcoded target triples.
- Lots of annotations throughout the standard library to make types, functions, protocols unavailable in embedded Swift (@_unavailableInEmbedded).
- Mainly this is about stdlib functionality that relies on existentials, type erasure, metatypes, reflection, string interpolations.
- We rely on function body removal of unavailable functions to eliminate the actual problematic SIL code (existentials).
- Many .swift files are not included in the compilation of embedded stdlib at all, to simplify the scope of the annotations.
- EmbeddedStubs.swift is used to stub out (as unavailable and fatalError'd) the missing functionality.
We trust the internal implementation of the stdlib to not cause any unintentional buffer overflows.
In such cases we can use the "unprotected" address-to-pointer conversions.
This avoids inserting stack protections where it's not needed.
* Use the "nearly divisionless" algorithm on all targets.
We have multipliedFullWidth available everywhere now, so we don't need to carry around the old implementation on 32b targets.
Also adds a few more benchmarks for random number generation.
* Obscure the range boundaries for some of the new random value benchmarks.
When these are visible compile-time constants, the compiler is smart enough to evaluate the division in the "nearly divisionless" algorithm, which makes it completely divisionless. That's good, but it obscures what the runtime performance of the algorithm will be when the bounds are _not_ available as compile-time constants. Thus, for some of the newly-added benchmarks, we pass the upper bound through `identity` to hide it from the optimizer (this is imperfect, but it's the simplest tool we have).
We don't want to do this for all the tests for two reasons:
- compile-time constant bounds are a common case that should still be reflected in our testing
- we don't want to perturb existing benchmark results more than we have to.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
* [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.
The functions in LibcShims are used externally, some directly and some through @inlineable functions. These are changed to SWIFT_RUNTIME_STDLIB_SPI to better match their actual usage. Their names are also changed to add "_swift" to the front to match our naming conventions.
Three functions from SwiftObject.mm are changed to SPI and get a _swift prefix.
A few other support functions are also changed to SPI. They already had a prefix and look like they were meant to be SPI anyway. It was just hard to notice any mixup when they were #defined to the same thing.
rdar://problem/35863717
- Fix error in `last(where:)` example
- Improve MemoryLayout, UnsafePointer, and integer operator discussions
- Clean up ranges and random APIs
- Revisions to overflow operators and the SignedNumeric requirements
- Standardize on 'nonoptional' in remaining uses
The function's definition is "Returns a random value that is less than the given upper bound," which cannot possibly be satisfied with upperBound == 0; previously the function returned zero, which was a bug.
This includes various revisions to the APIs landing in Swift 4.2, including:
- Random and other randomness APIs
- Hashable changes
- MemoryLayout.offset(of:)
Custom FixedWidthInteger types may not support this.
Introduce a new (non-public) FixedWidthInteger requirement for generating random values; implement it using &<</+ in the generic case, and specialize it using RandomNumberGenerator._fill(bytes) for the builtin types.
* Use the `__has_include` and `GRND_RANDOM` macros
* Use `getentropy` instead of `getrandom`
* Use `std::min` from the <algorithm> header
* Move `#if` out of the `_stdlib_random` function
* Use `getrandom` with "/dev/urandom" fallback
* Use `#pragma comment` to import "Bcrypt.lib"
* <https://docs.microsoft.com/en-us/cpp/preprocessor/comment-c-cpp>
* <https://clang.llvm.org/docs/UsersManual.html#microsoft-extensions>
* Use "/dev/urandom" instead of `SecRandomCopyBytes`
* Use `swift::StaticMutex` for shared "/dev/urandom"
* Add `getrandom_available`; use `O_CLOEXEC` flag
Add platform impl docs
Update copyrights
Fix docs
Add _stdlib_random test
Update _stdlib_random test
Add missing &
Notice about _stdlib_random
Fix docs
Guard on upperBound = 0
Test full range of 8 bit integers
Remove some gyb
Clean up integerRangeTest
Remove FixedWidthInteger constraint
Use arc4random universally
Fix randomElement
Constrain shuffle to RandomAccessCollection
warning instead of error
Move Apple's implementation
Fix failing test on 32 bit systems
* [stdlib] Revise documentation for new random APIs
* [stdlib] Fix constraints on random integer generation
* [test] Isolate failing Random test
* [benchmark] Add benchmarks for new random APIs
Fix Float80 test
Value type generators
random -> randomElement
Fix some docs
One more doc fix
Doc fixes & bool fix
Use computed over explicit
* Remove refs to Countable ranges
* Add `_stdlib_random` for more platforms
* Use `getrandom` (if available) for Android, Cygwin
* Reorder the `_stdlib_random` functions
* Also include <features.h> on Linux
* Add `#error TODO` in `_stdlib_random` for Windows
* Colon after Fatal Error
Performance improvement for Random
gybify ranges
Fix typo in 'basic random numbers'
Add _stdlib_random as a testable method
Switch to generic constraints
Hopefully link against bcrypt
Fix some implementation details
1. Uniform distribution is now uniform
2. Apply Jens' method for uniform floats
Fix a lineable attribute
Initial random api
Use C syscall for I/O
1. Fixed an issue where integers would would result in an infinite loop if they were unsigned, or signed integers always returning negative numbers.
2. Fixed an issue with Bool initialization
Add shuffle functions
Add documentation to Random API
Fix a few typos within the documentation
Fixes more typos
Also states that the range for floating points is from 0 to 1 inclusive
Update API to reflect mailing list discussions
Remove unnecessary import
Make sure not to return upperBound on Range
Use SecRandomCopyBytes on older macOS
Update API to match mailing list discussion, add tests
Added pick(_:) to collection
Added random(in:using:) to Randomizable
Added tests
Fix typo in Randomizable documentation
Rename pick to sampling
Move sampling below random
Update docs
Use new Libc naming
Fix Random.swift with new Libc naming
Remove sampling
gybify signed integer creation
Make FloatingPoint.random exclusive
Refactor {Closed}Range.random
Fix FloatingPoint initialization
Precondition getting a random number from range
Fix some doc typos
Make .random a function
Update API to reflect discussion
Make .random a function
Remove .random() in favor of .random(in:) for all numeric types
Fix compile errors
Clean up _stdlib_random
Cleanup around API
Remove `.random()` requirement from `Collection`
Use generators
Optimize shuffle()
Thread safety for /dev/urandom
Remove {Closed}Range<BinaryFloatingPoint>.random()
Add Collection random requirement
Refactor _stdlib_random
Remove whitespace changes
Clean linux shim
Add shuffle and more tests
Provide finishing tests and suggestions
Remove refs to Countable ranges
Revert to checking if T is > UInt64
