This way we configure correctly `libBlocksRuntime`, which is not using
`add_swift_target_library` (where the code for setting `OSX_ARCHITECTURES`
currently lives, see #38415 and #38956)
Addresses rdar://96469791
Defined SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY to describe
whether the standard library will use the task-to-thread model for
concurrency. It is true only for freestanding non-Darwin stdlibs.
When it is true, SWIFT_CONCURRENCY_TASK_TO_THREAD_MODEL is defined
during stdlib compilation of both Swift and C++ sources.
Added an option to LangOptions to specify which concurrency model is
used, either standard or task-to-thread. When
SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY is true, the model is
specified to be task-to-thread.
These are better done via the SwiftConfigureSDK mechanism rather than
how I was doing them previously. Additionally, I've changed the way
that the swift-threading-package option works. In addition to
specifying just a single package name, you can specify it as a CMake
list (i.e. separate by semicolons) of colon-separated `sdk:package`
pairs, e.g. `osx:darwin;linux:pthreads`. You can also override it
for all SDKs and then specify for a given SDK; specifications for a
particular SDK take precedence over the global override. For instance
`pthreads;osx:darwin` says to use `pthreads` except on the OS X SDK
where we should use `darwin`.
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
SWIFT_STDLIB_SINGLE_THREADED_RUNTIME is too much of a blunt instrument here.
It covers both the Concurrency runtime and the rest of the runtime, but we'd
like to be able to have e.g. a single-threaded Concurrency runtime while
the rest of the runtime is still thread safe (for instance).
So: rename it to SWIFT_STDLIB_SINGLE_THREADED_CONCURRENCY and make it just
control the Concurrency runtime, then add a SWIFT_STDLIB_THREADING_PACKAGE
setting at the CMake/build-script level, which defines
SWIFT_STDLIB_THREADING_xxx where xxx depends on the chosen threading package.
This is especially useful on systems where there may be a choice of threading
package that you could use.
rdar://90776105
This is some groundwork to make it possible to flip the `-enable-experimental-string-processing` flag on by default if and when it passes Swift Evolution. This PR itself do **not** change the defaults.
- Do not implicitly import _StringProcessing when building a module interface.
- Do not implicitly import _StringProcessing when core libraries, same as _Concurrency.
When SWIFT_COMPACT_ABSOLUTE_FUNCTION_POINTER is enabled, relative direct
pointers whose pointees are functions will be turned into absolute
pointer at compile-time.
Don't add the architecture to the library search path, because the output path also doesn't contain the architecture (for bootstrapping libraries)
rdar://90025270
Concurrency tracing was enabled depending on the presence of a header
file, but if a similarly named header was found somewhere in the path
that didn't do the same thing, that might cause problems.
Instead, we should have a build time configuration option.
rdar://89787540
The standard library cannot be built with MSVC's compiler. However, if
it is built with the toolchain which uses MSVC, it would fail to add
this flag. With recent VS2022 toolsets, this is a problem as we would
fail to be able to use the `offsetof` macro. Unconditionally apply the
definition when building the standard library.
* use quoted arguments when referencing "SWIFTLIB_SINGLE_SDK"
* break the first condition on multiple lines
This will make changes to these conditions easier to review.
The latest Long Term Support NDK finally removed binutils, including the bfd/gold
linkers and libgcc. This simplifies our Android support, including making lld the
default linker for Android. Disable three reflection tests that now fail, likely
related to issues with swift-reflection-dump and switching to lld.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
Introduce "SwiftStdlib x.y"-style availability macros for all known releases of the stdlib, adding them to the swift flags of all Swift libraries and tests.
