We needed to add the `Runtime` module to the new build system, but
when I tried doing that, various things broke.
Firstly, we ended up with two targets with the name `swiftRuntime`,
but only in the static build (because in that build, everything
gets pulled in together, so CMake sees both of them). Rename the
one that's part of `swiftCore` to `swiftRuntimeCore`.
Second, we need some extra paths for the `Cxx` module and its
submodules, and since those are part of the `INTERFACE`, we need
to make sure we `PUBLIC` link them into the `Cxx` module so that
they get passed through when building `swiftRuntime`.
rdar://101623384
Remove the SwiftCore_ENABLE_DIRECT_RETAIN_RELEASE option and the corresponding option from the various subprojects. Instead, unconditionally find_package(SwiftSwiftDirectRuntime) but without REQUIRED. We expect that if the compiler is emitting DirectRuntime calls, the library will be available, so there's no need to configure that separately.
Also refine the check for HasSwiftSwiftDirectRuntimeLibrary to exclude DriverKit.
Replace C++ implementation of swift_beginAccess and swift_endAccess with (almost) pure Swift implementation. Helpers remain in C++ for TLS, getting return addresses, and raising a fatal error on violations.
This change also moves the exclusivity access set head from the shared SwiftTLSContext structure to a dedicated TLS key. This improves performance, which is important for exclusivity checking. This is particularly the case where we can inline TLS access with a constant key, as on Darwin ARM64.
The code that bridges exclusivity tracking into Concurrency remains in C++. The new Swift implementation exposes a few helpers for it to use as a replacement for directly manipulating the C++ implementation.
rdar://161122309
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.
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
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)`.
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
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.
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.
Platform availability is an Apple concept because Swift is shipped as
part of the OS. It doesn't make sense to check or to warn on other
platforms. Only checking and setting it for Apple platforms.
This ensures that the libraries are properly linked and that we do not
have any unresolved symbols in the runtime (which are not satisfied by
its module dependencies).
The compiler will soon require that any module with a `.swiftinterface` be
built with an explicit language mode specified on the command line. This
prevents misinterpretation of the `.swiftinterface` when building it for
clients that aren't building with the default language mode.
Add explicit `-swift-version` arguments to the builds of various Runtimes
libraries to comply with this new requirement.
This leverages the SwiftDriver flag added in
https://github.com/swiftlang/swift-driver/pull/1941
Leave this disabled by default, so we can stage its adoption in Apple
vendor configurations.
Addresses rdar://158895783
When building a shared library on Windows, ensure that we export the
symbols. We would previously export none of the interfaces making the
dynamic library unusable. Simplify the macros as
`swiftRemoteMirror_EXPORTS` would only be defined when building a shared
library.
This extracts the version number computation out into a separate module
to be shared between the runtimes.
Setting `SWIFT_RUNTIME_VERSION` allows external build orchestration
tools to override the version number specified in source if necessary,
while centralizing the location of the default version number across the
runtime libraries.
Use the associated library name for the `CFBundleIdentifier` within the
plist. This will prevent cases where we have projects with multiple
targets referencing the project name itself (i.e swiftSwiftOnoneSupport
had it's bundle name set to SwiftCore)
