We've been hitting some issues where having the .swiftsourceinfo files
in the toolchain can cause hangs on macOS. Provide CMake-level control
for their generation so we can selectively enable them.
Fixes rdar://176894222
Add a new --enable-caching option that enables compilation caching for both
C/C++ (via clang-cache as compiler launcher) and Swift code (via
-cache-compile-job flags when bootstrapping=hosttools).
New options:
- --enable-caching: main toggle, incompatible with --sccache/--distcc
- --caching-cas-path: CAS directory (default: $BUILD_ROOT/cas)
- --caching-depscan-socket: depscan daemon socket path
- --caching-plugin-path: CAS plugin library path
- --caching-plugin-option: CAS plugin options (repeatable)
- --caching-prefix-map: enable source/SDK/toolchain prefix mapping
- --caching-remote-service-path: remote caching service with auto
plugin inference from Xcode and implied prefix mapping
The build script starts a clang-cache depscan daemon with reliable cleanup
via atexit and SIGTERM handlers. Per-product build directories get .cas-config
and compilation-prefix-map.json files written automatically.
Caching flags are applied to all Swift host compilation targets: compiler
sources, pure-swift host libraries (ASTGen, macros), swift-syntax, and
the new runtime build when --build-runtime-with-host-compiler is used.
When not using --caching-remote-service-path, enables CAS backend
(-Xfrontend -cas-backend -Xllvm -cas-friendly-debug-info) unless
SWIFT_CACHE_DISABLE_MCCAS is set.
A ninja wrapper is generated at build/<subdir>/build-utils/ninja for
cached incremental builds outside the build-script.
rdar://155876033
Assisted-By: Claude
* to check for the presence of the archiver, use `EXISTS`/`IS_DIRECTORY`
instead of `IS_EXECUTABLE`
* use `$<JOIN:...>` instead of `$<LIST:JOIN,...>` to compose the
archiving commands
* to be on the safe side, perform the check on the archiver only if
we are building the embedded stdlib
These are useful for debug backtraces when building against the binary
Swift modules. For Embedded Swift, it's even more important because
everything gets inlined. rdar://159398310
The feature was added only to avoid a reverse-condfail
in the initial bring-up of noncopyable generics.
Nearly 2 years have passed since the last time I tried
to remove this old technical debt [1] and had to revert
it due to outdated build bots [2]. Hoping that won't be
a problem this time.
[1] 5b2f2cbfcf
[2] https://github.com/swiftlang/swift/pull/75267
resolves rdar://131560183
when building non Darwin architectures with Xcode 26.4 beta 1 and later
-- the archiver that ships in Xcode is guaranteed to work only on MachO
object files, and will generate empty archives for other executable
formats.
This is a temporary solution while we add the support to build the
Embedded Swift stdlib in the new Runtimes build system.
Addresses rdar://171007411
`-define-availability` arguments for stdlib modules can be very long,
which may exceed Windows command-line length limits and cause build
failures. Use response files to avoid this.
Ever since `_BorrowingSequence` and friends landed in the standard library,
it's introduced a primary associated type that is suppressed. Since the mangling
of generic signatures is different depending on whether you're using
`SuppressedAssociatedTypes` and the `-WithDefaults` version, we should introduce
it with the new mangling in-place. It's also source breaking to make this switch
happen later on, since defaults will get assumed where they were not before.
rdar://170650908
We have a private oslog library to test optimizations specific for oslog.
Add -assert-config DisableReplacement to this library similar to the real oslog library.
This prevents surprizing optimizer regressions.
This doesn't have a working symbolicator yet, but it does build and
it can obtain a basic backtrace.
It also doesn't include a working `swift-backtrace` program yet.
rdar://101623384
This is second version of #85621 which was reverted in #85794 because
the result of `_compute_lto_flag` was used as a boolean in some
contexts.
The differences from the original is that `_compute_lto_flag` is split
into a second function `_is_lto_enabled` which provides an actual
boolean for when LTO is enabled, and the half dozen usages of
`_compute_lto_flag` have been audited for using `_compute_lto_flag`
without considering the return value a boolean, or using the new
`_is_lto_enabled` as a proper boolean. A small clean up of commented out
code is performed (probably just a forgetten clean up from #66077).
The changes have been verified by compiling with
`SWIFT_STDLIB_ENABLE_LTO=thin` and
`SWIFT_STDLIB_BUILD_TYPE=RelWithDebInfo`, and checking the resulting
flags for building the stdlib include both `-flto=thin` and
`-gline-tables-only`, while the Swift tools include `-fno-lto` instead.
The following is the original commit message, which explains why this
change is interesting:
---
When compiling Swift as an LLVM external project (not the non-unified
workflow from the build-script), if one tries to enable LTO for LLVM
projects it will end up affecting Swift and the Swift standard library,
even if the options `SWIFT_TOOLS_ENABLE_LTO` and
`SWIFT_STDLIB_ENABLE_LTO` are disabled or using their default values,
because [HandleLLVMOptions] modifies the `CMAKE_C/CXX_FLAGS` globally.
By setting `-fno-lto` explicitly when those options are disabled or
using their default values, the options from `CMAKE_C/CXX_FLAGS` are
overriden, and the `SWIFT_*_ENABLE_LTO` controls the usage or not of LTO
optimizations and the presence of bitcode in the object files.
[HandleLLVMOptions]:
https://github.com/swiftlang/llvm-project/blob/b58b2a34d5094928c4ee1b94a7d5412b14540c01/llvm/cmake/modules/HandleLLVMOptions.cmake#L1278-L1310
Stripping out the logic behind enabling concurrency tracing
independently of the rest of the standard library tracing. It's not
clear that there is a use-case where we want one without the other.
We don't want library evolution turned on for the Static SDK.
We can't do this in the `StdlibOptions.cmake` file because that's
testing the *host*, not the *target* (the code in there is wrong).
rdar://160455139
This fixes modularization errors that arise when importing a C++ header that contains `#include <guiddef.h>`, which might hijack this header from the WinSDK module where it belongs.
Where someone has told a target library to build for a _newer_ target
than the current deployment target, we need to respect that newer
target when setting StdlibDeploymentTarget for that target library.
This trips us up when testing against older systems.
rdar://155841439
`line-directive` was expanding response files for the swiftc invocation,
which was causing issues on CI when the file list got too long. This
changes the script to stop expanding response files and pass them as-is
to the swiftc invocation instead. The format for the response files was
also incorrect, with each individual file being quoted, so this fixes
the CMake script generating those.
Finally, this changes `line-directive` to dump the command line on
failure.
Add catalyst support for SwiftStdlibCurrentOS.
Also, set a minimum deployment target when building Concurrency;
this stops the build failing when we're trying to build on older
systems where Concurrency didn't really exist yet.
rdar://150966361
If you use SwiftStdlibCurrentOS availability, you will be able to
use new types and functions from within the implementation. This
works by, when appropriate, building with the CurrentOS availability
set to the current deployment target.
rdar://150944675
This fixes a deserialization failure in the compiler that occurred while loading the CxxStdlib overlay module:
```
Cross-reference to module 'Swift'
... Optional
... some
... with type <τ_0_0 where τ_0_0 : ~Copyable, τ_0_0 : ~Escapable> (Optional<τ_0_0>.Type) -> (τ_0_0) -> Optional<τ_0_0>
```
This was happening because the overlays were built against a different version of the Swift stdlib than is being used. The compiler is able to rebuild the Cxx and CxxStdlib modules from their textual interfaces. Let's use that feature unconditionally in production toolchains to avoid this kind of binary incompatibilities.
rdar://150416863
Doug Gregor
Steven Wu
Allan Shortlidge
Eric Miotto
Eric Miotto
Kavon Farvardin
Slava Pestov
Rintaro Ishizaki
susmonteiro
Meghana Gupta
Meghana Gupta
Alastair Houghton
Daniel Rodríguez Troitiño
Alejandro Alonso
Evan Wilde
Mads Odgaard
Erik Eckstein
Egor Zhdan
Marc Prud'hommeaux
Fabrice de Gans
Finagolfin
Kuba Mracek
Guillaume Lessard
QuietMisdreavus
Artem Chikin