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
Stripping out the logic behind enabling concurrency tracing
independently of the rest of the standard library tracing. It's not
clear that there is a use-case where we want one without the other.
Switching the concurrency runtime to use the common SWIFT_STDLIB_TRACING
to control whether the concurrency runtime enables tracing. The old
process required passing bot the `SWIFT_STDLIB_TRACING` and
`SWIFT_STDLIB_CONCURRENCY_TRACING` macro to the concurrency build or it
would fail to build.
It's not clear that there are any environments where it is desirable
for swiftCore to have tracing enabled and not have swift_Concurrency
tracing enabled or vice versa. Replacing the concurrency-specific macro
with a single common macro. If it is desirable, we can teach the build
system to avoid passing `SWIFT_STDLIB_TRACING` to a specific target if
an option is not set.
rdar://165777240
