swiftCore and swift_Concurrency libraries use C++ and Swift. The C++
does not use the Swift C++ interop. Swift driver only uses clang++ to
link when building in C++ interop mode and there currently isn't a flag
to change that. Since we're explicitly linking the runtime registration
when necessary and do not need compatibility libraries, it is safe to
use clang++ as the linker directly, instead of going through swiftc.
In versions of CMake older than 3.29, Swift is always used as a linker
and has no compile stage. By using clang++ as the linker, we require the
split build model (CMP0157), so we cannot allow versions of CMake older
than 3.29.
Explicitly add the path to the Swift module to the interface include
directories. It is unclear why this is not propagating implicitly from
the module definition. For now, this ensures that the client is able to
load the standard library.
When building the runtime, we do not know how it will be loaded even if
it is static. Default to building in PIC mode for non-Windows targets
(Windows is always implicit PIC).
This is required to use the SwiftCore package externally via
`find_package` when Concurrency is enabled. We are otherwise unable to
process the CMakeLists due to the missing dependency from the export
set.
This re-organises the file a small amount to put the source listing and
additions together. Subsequently, apply compile definitions, options,
and then link libraries and finally options
This adjusts the default settings for the Windows build of the Swift
runtime to include reflection and to re-order them to match the Darwin
configuration to make it easier to identify differences.
This is loaded by the CMake package configuration so that you can add
cross-package dependencies. Adjust the path so that the lookup succeeds
on all targets.
`swiftrtT.obj` should be used for statically linking the standard
library (or within the standard library itself). For the other modules,
we need to differentiate between `swiftrt.obj` and `swiftrtT.obj`. This
fixes that oversight. This was not caught by the CI builds as we do not
currently build both the static and dynamic variants of the new
runtimes.
Add cmake cache for enabling sccache while building with the new runtime
build when sccache is available.
To build with sccache, pass the `sccache.cmake`
```
cmake \
-B build \
-S Runtime/Core \
-C Runtimes/Core/cmake/cache/sccache.cmake
```
We introduce a new macro called #SwiftSettings that can be used in conjunction
with a new stdlib type called SwiftSetting to control the default isolation at
the file level. It overrides the current default isolation whether it is the
current nonisolated state or main actor (when -enable-experimental-feature
UnspecifiedMeansMainActorIsolated is set).
This adjusts the spelling for the architecture specifier for the Windows
compilers. Take the opportunity to further restrict the compiler check
to micro-optimize the CMake configure phase.
Optimization remarks were always emitted on Darwin but not on the other
platforms and were forced to use the bitstream format. Adding a flag to
enable or disable them as desired and specify the desired output format.
Fixes: https://github.com/swiftlang/swift/issues/79279
Extracting experimental feature flags into a separate file so that we
can add Allan as a code owner of just that file. He has to deal with
breakage when folks remove these flags improperly.
* [Concurrency] Initial steps for startSynchronously for Task
* [Concurrency] Rename to _startSynchronously while in development
* [Concurrency] StartSynchronously special executor to avoid switching
* startSynchronously bring back more info output
* [Concurrency] startSynchronously with more custom executor tests
* add missing ABI additions to test for x86
* [Concurrency] gyb generate _startSynchronously
* [Concurrency] %import dispatch for Linux startSynchronously test
* [Concurrency] Add TaskGroup.startTaskSynchronously funcs
* [Concurrency] DispatchSerialQueue does not exist on linux still
The driver just changed where it looks for swiftrt.o when performing a
static-stdlib build from always looking under `/usr/lib/swift` to
`/usr/lib/swift_static`.
This change of behavior comes from:
7156812d251d0f4dd6e7c605940f7e5497eaa795
The dispatch global executor depends on finding dispatch. If dispatch is
not found, it will fail to build. Mark it as required to get a
configuration failure early.
We need to define the defaulted setting so that it pulls in the default
value. Otherwise we hit a configuration failure in
`Concurrency/CMakeLists.txt` when it includes the config file specific
to the global executor because `SwiftCore_CONCURRENCY_GLOBAL_EXECUTOR`
is an empty string.
Implementing an initial `Finddispatch.cmake` module to find Dispatch
from the system SDK on Apple platforms. Still should implement a basic
mechanism for finding it on Windows and Linux. Note that those platforms
will likely use the dispatch config mechanism most frequently, but this
should still work as a fallback.
This mechanism is the only one that works for Apple platforms though as
those use libdispatch from the SDK rather than building it with
corelibs-libdispatch.
When building for Linux and Windows, it is possible to build a custom
corelibs-libdispatch runtime with `dispatch_DIR` and avoid this module.
This module makes it possible to use a pre-built corelibs-libdispatch
when one is available without needing to build it. The module uses
the `Swift_SDKROOT` filepath as a hint on where to look for the runtime
libraries and the `dispatch_STATIC` boolean to specify whether it should
find the dynamic library or the static archive.
Starting to work on a full installation story for the Swift runtimes.
This involves generating the SwiftCoreConfig cmake files to allow
importing the just-built runtimes into the overlays and supplemental
libraries, setting up the flags appropriately for the given SwiftCore
build configuration.
This also separates out the development and runtime components to allow
installing just the runtimes without the headers.
Component List:
- SwiftCore_runtime
The runtime libraries that are required for running code.
- SwiftCore_development
The interface with the runtime libraries that are required for
building code against the runtimes.
- SwiftCore_cmake
Files for interfacing CMake projects with the built runtimes.
This includes the target list and flags needed to use the targets
built by the specific configuration used to build the runtime
libraries.
These files are used for mapping flags, definitions, and locations
into the overlay libraries and supplemental libraries.
This adds install commands for the object libraries contributing to
libswiftCore so that they are represented in SwiftCoreTargets.cmake.
Object libraries do not contribute anything to the files actually
installed.
`__progname` is not available on Windows, and is provided by libbsd on
Linux. This provides a replacement for the functional aspect of the
symbol on Windows.
The stdlib needs to build in Swift-5 mode, and ensure that
`-swift-verion 5` be included in the commandline explicitly. While the
compiler defaults to 5 mode, if it's not included explicitly, it won't
be included in the swift interface, which then means that modules that
import it will influence how the textual interface is processed.
The interface for the stdlib must be processed in the Swift 5 language
mode due to sendability. Set it explicitly to ensure that importing
modules do not change the Swift language mode.
Fixes: rdar://145118843
