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
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
Fixing sources used to build synchronization library. This aligns the
synchronization source list with what is posted in the old build system.
```
set(SWIFT_SYNCHRONIZATION_DARWIN_SOURCES
Mutex/DarwinImpl.swift
Mutex/Mutex.swift
)
set(SWIFT_SYNCHRONIZATION_LINUX_SOURCES
Mutex/LinuxImpl.swift
Mutex/Mutex.swift
Mutex/SpinLoopHint.swift
)
set(SWIFT_SYNCHRONIZATION_FREEBSD_SOURCES
Mutex/FreeBSDImpl.swift
Mutex/Mutex.swift
)
set(SWIFT_SYNCHRONIZATION_WASM_SOURCES
Mutex/Mutex.swift
Mutex/WasmImpl.swift
)
set(SWIFT_SYNCHRONIZATION_WINDOWS_SOURCES
Mutex/Mutex.swift
Mutex/WindowsImpl.swift
)
set(SWIFT_SYNCHRONIZATION_OPENBSD_SOURCES
Mutex/Mutex.swift
Mutex/OpenBSDImpl.swift
)
```
This is specifically to fix this error when building for Linux:
```
/build/swift/Runtimes/Supplemental/Synchronization/Mutex/LinuxImpl.swift:99:19: error: cannot find '_tries' in scope
97 | // This value is controlled on a per architecture bases defined in
98 | // 'SpinLoopHint.swift'.
99 | var tries = _tries
| `- error: cannot find '_tries' in scope
100 |
101 | repeat {
/build/swift/Runtimes/Supplemental/Synchronization/Mutex/LinuxImpl.swift:126:9: error: cannot find '_spinLoopHint' in scope
124 | // effect of slowing down this loop if only by a little to preserve
125 | // energy.
126 | _spinLoopHint()
| `- error: cannot find '_spinLoopHint' in scope
127 | } while tries != 0
128 | }
ninja: build stopped: subcommand failed.
```
This eliminates UnicodeData.h from the public SwiftShims. A small
part of it remains as a private header, but everything else moves
into `@_extern(c)`.
...optimization in Apple vendor configurations.
This is needed to avoid increasing the
size of the associated dylibs.
Take this chance to remove the `-enable-ossa-modules` flag when building
Runtimes, since that's a noop now.
Addresses rdar://165699017
Adding the Glibc Clang Overlay interface target to the installed export
set. The interface library exists to plumb the appropriate flags through
the build graph and ensure that the modulemap and header file are
generated when depended on.
Interface libraries need to be in the export set when depended on by a
public library to ensure that the appropriate install interface flags
are exposed to targets importing the library from outside of the build
system, regardless of whether the interface library actually installs
any files.
This fixes the configuration-time error:
Export called with target "swiftGlibc" which requires
"SwiftGlibcClangOverlay" that is not in any export set.
At the moment we are not building that natively in the new build system,
so find the copy built by the legacy one using a find module.
Keep this disabled for the time being.
Addresses rdar://164174616
higher in case sensitive directory listings (like GitHub).
This will ease checking for stdlib code on small screens without needing
to scroll.
Addresses rdar://164195263
As per 7b19531291
CMake 4.0 does not pass `-sdk` to compiler invocations if the user does
not provide `CMAKE_OSX_SYSROOT` -- this in turn causes failures in
linking.
Addresses rdar://163672815
Adding a new glibc overlay for Linux builds. We will eventually need one
for Musl, and if someone really wants to, LLVM and cosmopolitan libcs
are also out there.
When we enable the early swift-driver, CMP0157 will be enabled, changing
the linker language for the library, changing the library prefix.
Correct this for that scenario.
Updating the todo list comments.
- Windows builds are already using the runtime build system to build
the runtimes so we can remove that from the todo list.
- The Android SDK on Windows is currently cross-compiled with the new
runtime build.
- Catalyst builds have been going for a bit now, generating the
necessary bits.
- We moved things to a nested swiftmodule structure, which installs the
entire directory, containing all of the emitted products.
The Glibc Linux builds should be coming soon.
We still have embedded to work on.
Explicit module builds crash the compiler when building the glibc
overlay library. The crash occurs in the Swift driver dependency
scanner. It appears to be related to vfs overlays, modulemaps,
injected header files, and explicit module builds.
This is odd though because the Android builds also have this
combination, but work.
Adding the additional driver outputs in the cleanup files. This cleans
up the warnings from `ninja clean`.
```
Cleaning... ninja: error: remove(clang/_Builtin_float.swiftmodule): Directory not empty
```
This is a small refactor to rename the build module directory,
"${CMAKE_CURRENT_BINARY_DIR}/${module_name}.swiftmodule" to
"${module_directory}" to make it more concise.
