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
Previously it would print this:
```
[3/3] Linking CXX executable bin/swift-frontend; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ;
```
Now we only pass the comment through if it is set, so those go away
Prior to this change, we used versioned triples on this platform.
However, swift-build and the planned future migrations effectively
constrain the platform to abandon this module naming scheme.
Ideally, we would look for a swiftmodule named after the versioned
triple, then fall back to the unversioned triple, or vice versa.
However, this is not straightforward to do, and/or would induce a larger
change. It transpired that it was more straightforward to just convert,
despite reservations and modules generated on earlier versions requiring
recompilation in the future. Because the install base for the platform
is likely few, tackle the work to implement the fallback later and just
get this quickly done first, especially so we can hopefully make the cut
to have this incorporated in 6.3.
SourceKit always needs sourcekit-inproc. With this change we always get
a `lib/sourcekitdInProc.framework` directory in the swift build
directory. This can then be used in SourceKit-LSP to run SourceKitD
in-process on macOS for debugging.
Ensure that we build with `/DUNICODE /D_UNICODE` on Windows to enable
the unicode paths.
Remove a workaround for `_DEBUG` in light of llvm/llvm-project#183120.
Take the opportunity to reflow some text and add some explanatory
comments.
Fixes: #87470
Sadly MSVC doesn't seem to have a equivalent to `-fno-lto` and it does
not like `-fno-lto`, printing a warning. Pointed out after landing in
the comments of #86187.
In order to avoid the warning, skip the `-fno-lto` flag for MSVC
compilers. This means that MSVC will still suffer the problem described
in #86187 (enabling LTO in a LLVM unified build will force enabling LTO
on Swift/Swift stdlib, even if disabled explicitly with\
`SWIFT_STDLIB_ENABLE_LTO`). This was the result even after #86187, since
MSVC was ignoring the `-fno-lto` anyway.
It cannot be done with a generator expression because the resulting
string seems to be used in some context that does not support generator
expressions.
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
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
On older x86_64 hardware, this isn't a problem since CET IBT hardware
support may not have been available. However, newer x86_64 hardware
supports the feature, which will lead to BTCFI failures. Therefore ensure
the same BTCFI disabling logic applies on x86_64 as well as aarch64.
When building the swift compler with "Debug" configuration, modules
written in Swift must be linked to swiftOnoneSupport. Explicitly link it
as some linker doesn't auto-link it.
rdar://162631685
For hosts that have a swiftly-managed Swift compiler, we could not
bootstrap using those tools, because of some hardcoded assumptions
about where the `/lib` directory lives, relative to the `/bin`
directory that contains the detected `swiftc`.
This patch adds specific support for detecting when the `swiftc`
is coming from a swiftly install and uses the correct paths.
I've tested this patch on my Linux machine that has swiftly 1.0.1,
with the Swift 6.1.2 toolchain.
LLVM FreeBSD triples include the version number, which gets encoded into
the swiftmodule. The filename should not include the version number
though. This patch drops the version number from the filename, but not
from the target triple.
This fixes several tests which uses the computed target triple as the
flag to pass to `-target`. Since it was missing the version number, the
compiler assumed it defaulted to zero and would report
"compiling for freebsd 0, but module 'Dispatch' has a minimum deployment
target of freebsd 14.3"
Fixes: rdar://156163594
Currently we are using the same versions we use to build compiler and
standard library. This is an unnecessary coupling especially when
testing the generation of backdeployed executables for macOS -- here
we have interest in being able to run the tests on previous OSes, not
the compiler itself.
To support this, add new `--darwin-test-deployment-version-<platform>`
flags to build-script, which by default take the same value as the
matching `--darwin-deployment-version-<platform>` ones.
Addresses rdar://156724078
The tests broke on the community Android CI since #82325, and I just
noticed the install issue when cross-compiling Testing with a
freshly-built compiler, which I'd never done before. Also, fix the NDK
path shown in the CMake output.
The SDK overlays have been provided in the Apple SDKs for many years, and the interface and implementation has diverged in more recent years such that trying to build the Swift version no longer works. Remove all of the dead code.
rdar://151889154
The 64-bit ARM architecture spelling on FreeBSD is aarch64, not arm64.
This results in a build failure about a missing
`freebsd/arm64/swiftrt.o` while building the runtimes.
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 is a little less than ideal, since as I understand it, it only
makes sense to add -z,origin when $ORIGIN expansion is required, but
doing this surgically per target is rather cumbersome. I don't believe
there are any significant drawbacks to doing it unconditionally like
this, however.
The SimplifyCFG and LoopRotate passes result in verification failures
when built in a compiler that is not built with Swift sources enabled.
Fixes: rdar://146357242
Emitting modules in separate frontend job doesn't give any benefits
because single add_library is just a single job from CMake's point of
view. Clients need to wait for `.dylib`/`.so` being emitted before using
the `.swiftmodule`. *Not* emitting modules separately is actually faster
in CMake because it doesn't parse and typecheck the source code twice.
Package CMO requires '-enable-library-evolution' in 6.1+ compilers.
Otherwise:
<unknown>:0: error: Library evolution must be enabled for Package CMO
rdar://146673779
This patch adds initial support for Emscripten SDK alongside the existing
support for WASI SDK. This is a first step towards building a part of
Swift compiler for Emscripten target (which will be used to build LLDB
with Swift to WebAssembly target).
This was quite brittle and has now been superseded
by swift-xcodegen. Remove the CMake/build-script
logic for it, leaving the option behind to inform
users to switch to using xcodegen instead.
* Reapply '[BuildSystem] Stop building for i386-watch-simulator (#77692)'
* [BuildSystem] Stop building for i386-watch-simulator
In Xcode16 it is not supported.
This initially broke client projects who were still building the legacy
architecture but now that's resolved.
Steven Wu
Doug Gregor
Keith Smiley
3405691582
Steffeeen
Rintaro Ishizaki
Saleem Abdulrasool
Saleem Abdulrasool
Daniel Rodríguez Troitiño
Fabrice de Gans
Kavon Farvardin
Evan Wilde
Eric Miotto
Yuta Saito
finagolfin
(null)
Alastair Houghton
Konrad `ktoso` Malawski
Ian Anderson
Hamish Knight
Michael Chiu
Cyndy Ishida