`_swift_stdlib_configure_console_mode` reverts console codepage on Windows using `atexit`, which is declared in `stdlib.h`.
Add the missing `#include <stdlib.h>` to unblock building Swift `stdlib` with MSVC v14.37 (Visual Studio 17.7).
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
This removes the explicit tree structure reference in the stubs to
locate the shims. Instead, it expects that the `SwiftShims` directory
will be added to the header search path.
This adjusts the Windows console to switch the codepage to UTF-8. This
is important as the default codepage (CP437) does not allow for UTF-8
output, but expects ASCII. However, strings in Swift are assumed to be
UTF-8, which means that there is now a conversion mismatch.
Because the console mode persists beyond the duration of the application
as it is state local to the console and not the C runtime, we should
restore the state of the console before termination. We do this by
registering a termination handler via `atexit`. This means that an
abnormal termination (e.g. via `fatalError`) will irrevocably alter the
state of the console (interestingly enough, `chcp` will still report the
original console codepage even though the console will internally be set
to UTF-8).
Fixes: SR-13807
Most SwiftShims were put in the swift namespace in C++ mode which broke certain things when importing them in a swift file in C++ mode. This was OK when they were only imported as part of the swift runtime but, now they are used in C++ mode both in the swift runtime and when C++ interop is enabled.
This broke when C++ interop was enabled because the `Swift` module contains references to symbols in the SwiftShims headers which are built without C++ interop enabled (no "swift" namespace). But, when C++ interop is enabled, the SwiftShims headers would put everything in the swift namespace meaning the symbols couldn't be found in the global namespace. Then, the compiler would error when trying to deserialize the Swift module.
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.
