Revert #20194, which seems to be more trouble than it's worth. Instead, move the functions that SwiftPrivate needs back into LibcShims.h/cpp as SPI.
rdar://problem/45817565
`ssize_t` is not universally available as it is not a standard type.
However, we require clang to build the runtime due to custom calling
convention support. As a result, we know that the compiler will support
the `_Generic` keyword from the C11 standard. Use this with an
expansion to map the type appropriately for all targets. This avoids
having to have a sanity check in the runtime that the type definition
matches the underlying system.
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
Instead of only requiring Glibc's implementation of getrandom, try to use a direct syscall to getrandom. This should allow more versions of linux to utilize getrandom instead of always having to fallback to reading /dev/urandom.
SwiftPrivate/PRNG.swift:
- currently uses `theGlobalMT19937`;
- previously used `arc4random` (see #1939);
- is obsoleted by SE-0202: Random Unification.
This includes various revisions to the APIs landing in Swift 4.2, including:
- Random and other randomness APIs
- Hashable changes
- MemoryLayout.offset(of:)
* 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
* 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
* Cleanup tgmath wrappers.
- Remove special-case gyb logic for lgamma on Darwin; the symbols we need are always present, even if not visible in the headers, so we only need a prototype.
- Add some deprecations for symbols that have direct stdlib analogues.
- Make some operations generic on [Binary]FloatingPoint, where they can map to the protocols instead of calling libm.
- Mark ldexp(Float/Double) renamed to scalbn; for binary formats these are identical functions, and we don't really want to use these names for hypothetical future Decimal support, as they're not Swifty.
Windows x86 requires that the TLS destructor callback uses the "stdcall"
calling convention. Provide a shim which will adjust the calling
convention and call back into the swift portion of the code code with
the expected calling convention.
Rename the explicit `pthread` to `thread` to indicate that this is not
`pthread` specifically. This allows us to implement the TLS support for
Windows using Fibers.
Adds in Linux platform support for our pthread TLS. Replace usage of
PTHREAD_KEYS_MAX with a sentinel value, as it's tricky to define
cross-platform and was only lightly used inside sanity checks.
Introduce shims for using UBreakIterators from ICU. Also introduce
shims for using thread local storage via pthreads.
We will be relying on ICU and UBreakIterators for grapheme
breaking. But, UBreakIterators are very expensive to create,
especially for the way we do grapheme breaking, which is relatively
stateless. Thus, we will stash one or more into thread local storage
and reset it as needed.
Note: Currently, pthread_key_t is hard coded for a single platform
(Darwin), but I have a static_assert alongside directions on how to
adapt it to any future platforms who differ in key type.
Adds in Linux platform support for our pthread TLS. Replace usage of
PTHREAD_KEYS_MAX with a sentinel value, as it's tricky to define
cross-platform and was only lightly used inside sanity checks.
Introduce shims for using UBreakIterators from ICU. Also introduce
shims for using thread local storage via pthreads.
We will be relying on ICU and UBreakIterators for grapheme
breaking. But, UBreakIterators are very expensive to create,
especially for the way we do grapheme breaking, which is relatively
stateless. Thus, we will stash one or more into thread local storage
and reset it as needed.
Note: Currently, pthread_key_t is hard coded for a single platform
(Darwin), but I have a static_assert alongside directions on how to
adapt it to any future platforms who differ in key type.
* Go back to using static inline implementations of sqrt and remainder now that SR-2089 is resolved.
* Fix typo: sqrt -> squareRoot.
* Added test for constant-folding sqrt with -O.
* Added test case requested by jrose.
* Use intrinsics instead of Libc stubs where we can.
This replaces most of the stubs used for basic operations on these
types with intrinsics, eliminating a level of indirection for fma,
ceil, floor, round, trunc.
square root and remainder still require stubs because there is no
remainder intrinsic and we can't use the square root intrinsic because
its behavior is undefined for negative inputs. A previous commit
apparently either the compiler annotates static inline stubs wrong
or the SIL verifier can't handle them, so that change was backed out.
* Explicitly CHECK-NOT @llvm.sqrt instead of looking for @sqrt.
This reverts commit 999885fc8d.
This breaks the stdlib serialization tests:
Assertion failed: (!hasSharedVisibility(F->getLinkage()) && "external declaration of SILFunction with shared visibility is not " "allowed"), function visitSILFunction, file /s/sptr/swift/lib/SIL/SILVerifier.cpp, line 3267.
Implemented SE-0113 + residual SE-0067 operations.
- adds `rounded` and `round` to `FloatingPoint`, from SE-0113.
- adds `remainder`, `squareRoot`, and `addingProduct`, from SE-0067.
- adds basic test coverage for all of the above.
- provides a default implementation of `nextDown` on `FloatingPoint`.
To minimize code size and VM live set, we try to funnel all one-time initialization through swift_once instead of mixing it with the C++ runtime's support for lazy static initialization.
These two symbols were not correctly scoped, placing them inside of the swift
namespace. This would change the linkage names and fail to link as a result.
Scope one as the header properly places it in an extern "C" block. The gyb file
is unable to find the desired runtime header, so explicitly mark the exported
symbol as being exposed with C linkage.
The general rule here is that something needs to be SWIFT_CC(swift)
if it's just declared in Swift code using _silgen_name, as opposed to
importing something via a header.
Of course, SWIFT_CC(swift) expands to nothing by default for now, and
I haven't made an effort yet to add the indirect-result / context
parameter ABI attributes. This is just a best-effort first pass.
I also took the opportunity to shift a few files to just implement
their shims header and to demote a few things to be private stdlib
interfaces.
- Update the documentation to reflect that Swift supports (only)
the latest NDK version. Based on what I've heard from Android
developers that use the NDK, this is a reasonable requirement.
- The most recent version of the Android NDK no longer includes a
"4.8" toolchain version. Change the default to "4.9", and update
the paths in the documentation to match.
- The build script option "--android-ndk-version" was misleading.
This parameter actually refers to the Android API level. Swift
currently supports 21 (Android 5.0) and above (although supporting
lower API levels would be desirable).
