Android NDK, as of version 28, does not include the `ptrauth.h` header. This causes CI failures when building the Swift SDK for Android on Windows.
rdar://166242941
There is an existing cache which is built when looking up
FieldDescriptors. collectAllConformances ignored this cache and would
parse every FieldDescriptor again. Use the existing cache mechanism.
rdar://166098516
After further thought, I realize that it makes more sense
to keep the public API in FloatingPointParsing.swift.gyb
(where we can consolidate the repetitive doc comments)
and have this as a purely internal set of service functions.
This reverts commit 7084ab8e6e.
LLVM no longer tail-calls this on x86_64, so we do not need an autorelease pool. Remove it for i386 as well as that is no longer a target for ObjC interop builds.
This reimplements the underlying support for `Float16(_:StringSlice)`,
`Float32(_:StringSlice)`, and `Float64(_:StringSlice)` in pure Swift,
using the same core algorithm currently used by Apple's libc. Those
`StringSlice` initializers are in turn used by `Float16(_:String)`,
`Float32(_:String)`, and `Float64(_:String)`.
**Supports Embedded**: This fully supports Embedded Swift and
insulates us from variations in libc implementations.
**Corrects bugs in Float16 parsing**: The previous version of
`Float16` parsing called libc `strtof()` to parse to a 32-bit float,
then rounded to `Float16`. (This was necessary because float16
parsing functions are not widely supported in C implementations.)
This double-rounding systematically corrupted NaN payloads and
resulted in 1 ULP errors for certain decimal and hexadecimal inputs.
The new version parses `Float16` directly, avoiding these errors.
**Modest perforamnce improvement**: The old version had to copy
the Swift string to construct a C string. For inputs longer than
15 characters, this typically required a heap allocation, which added
up to 20% to the runtime. The new version parses directly from a Swift
string, avoiding this copy and heap allocation.
_math would be able to build against either the Swift or the clang
module for _Builtin_float; however the build will fail if the Swift
module is present but does not contain the architectures we need, with errors
like
```
<unknown>:0: error: could not find module
'_Builtin_float' for target 'armv7-unknown-linux-android'; found:
aarch64-unknown-linux-android, x86_64-unknown-linux-android, at:
/home/build-user/build/swift-project/Ninja-Release/swift-linux-x86_64/lib/swift/android/_Builtin_float.swiftmodule/armv7-unknown-linux-android
```
In other words, in this situation we are not falling back to the clang
module.
Addresses rdar://165768601
This introduces support for converting a Swift closure that captures variables from its surrounding context into an instance of `std::function`, which is useful for working with C++ APIs that use callbacks.
Each instantiation of `std::function` gets a synthesized Swift constructor that takes a Swift closure. Unlike the previous implementation, the closure is _not_ marked as `@convention(c)`. The body of the constructor is created lazily.
Under the hood, the closure is bitcast to a pair of a function pointer and a context pointer, which are then wrapped in a C++ object, `__SwiftFunctionWrapper`, that manages the lifetime of the context object via calls to `swift_retain`/`swift_release` from the copy constructor and the destructor. The `__SwiftFunctionWrapper` class is templated, and is instantiated by ClangImporter.
rdar://133777029
