We need this so that older compilers can handle the .swiftinterface
files we generate. It's unnecessary for newer compilers and can be
removed later.
Fixes rdar://148529962.
Explicit module builds help prevent the dependency scanner from getting
lost and attempting to pull the SwiftShims module from the resource
directory, existing SDK, and the just-built standard library.
They aren't part of the library interface, but make it possible to build
the runtime libraries without seeing duplicate shims. Moving the flag to
a top-level compile command.
The expected install locations for the SwiftCoreConfig.cmake and
SwiftCoreTargets.cmake file was inconsistent between the build directory
and the install location. Making everything consistent across install
locations. In both cases, the files are installed under
`./cmake/SwiftCore`. This is one of the formats that `find_package` uses
to automatically search for package config files so that we can avoid
passing `SwiftCore_DIR` to all sub-projects.
This removes the workaround for the exporting of the registrar and
enables proper dependency tracking across projects (primarily geared
towards the Overlay).
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
