Commit e0bba70 added a default implementation, however this is wrong
for non-imported types.
Instead, synthesize the body as before. Since this is one of the few
derived methods that can appear on an imported type, make sure to
build fully type-checked AST.
Fixes <rdar://problem/51322302>.
* [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.
Android doesn't support the GNU backtrace call, but unwind.h is there to
help. The code is a little bit more complicated than a simple backtrace
call, but it is just a callback and the context struct.
Sadly, it seems that -funwind-tables is needed in every piece of code
that the backtrace needs to traverse, which means that at least the
runtime and the stubs need -funwind-tables. However, the flag has been
enabled for all targets (only on Android), just in case some other code
ends up being in the stack. This might only be necessary for ARM
targets, but currently we only build ARM targets in Android. The Swift
parts of the stack seems to have unwind information and can be unwind.
Another problem at the moment is the symbols from the executable are
normally missing. To get symbol names two things need to happen: the
symbol has to be public (so it is an exported symbol, and not just a
local symbol that dladdr seems to not provide the name), and the linker
has to be invoked with -export-dynamic. Without those two pieces, the
addresses are returned (and match the binary just fine), but no names
are printed.
When building without assertions, the variable will be unreferenced on
non-ObjC runtimes. Sink the evaluation into the assertion and move the
declaration into the ObjC runtime case.
* [Foundation] Fix availability of NSValue.value(of:)
(cherry picked from commit fbe5563d60)
* [Foundation] NSValue.value(of:): Reinstate runtime OS version check
Although it's a static archive, its use is only relevant to dynamically linked builds of the
standard library. (If you're statically linking a Swift runtime into your process, you don't
need to worry about compatibility with older runtimes.)
Many build systems that support Swift don't use swiftc to drive the linker. To make things
easier for these build systems, also use autolinking to pull in the needed compatibility
libraries. This is less ideal than letting the driver add it at link time, since individual
compile jobs don't know whether they're building an executable or not. Introduce a
`-disable-autolink-runtime-compatibility` flag, which build systems that do drive the linker
with swiftc can pass to avoid autolinking.
rdar://problem/50057445
Instead of a thunk insert the dispatch into the original function.
If the original function should be executed the prolog just jumps to the "real" code in the function. Otherwise the replacement function is called.
There is one little complication here: when the replacement function calls the original function, the original function should not dispatch to the replacement again.
To pass this information, we use a flag in thread local storage.
The setting and reading of the flag is done in two new runtime functions.
rdar://problem/51043781
This splits out the bionic modulemap from the glibc modulemap. They are
sufficiently different that the duplication is worth it. Furthermore,
it will enable properly identifying the libc on android. Once fully
detangled, this will enable the use of bionic on non-android platforms.
Build a static archive that can be linked into executables and take advantage of the Swift runtime's
hooking mechanism to work around the issue Doug fixed in https://github.com/apple/swift/pull/24759.
The Swift 5.0 version of swift_conformsToProtocol would return a false negative in some cases where
a subclass conforms using an inherited conformance, so work around this by successively retrying
the original implementation up the superclass chain to try to find a match.
