- **Explanation**: Renames the WebAssembly target triple from `wasm32-unknown-wasi` to `wasm32-unknown-wasip1` to align with the broader WebAssembly ecosystem's naming conventions. It's important to include this in 6.2, which is going to be the first stable release of Swift SDK for Wasm, so that we won't introduce a breaking triple change in the stable version series later.
The WebAssembly ecosystem has been migrating from the generic wasi target name to more explicit version-specific names like `wasip1` and `wasip2`. This change has been adopted across multiple toolchains and language ecosystems:
- Rust: Renamed `wasm32-wasi` to `wasm32-wasip1` (https://github.com/rust-lang/compiler-team/issues/607)
- wasi-sdk: Renamed `wasm32-wasi` to `wasm32-wasip1` (https://github.com/WebAssembly/wasi-sdk/pull/386)
- Go: Already uses `wasip1` naming convention (https://github.com/golang/go/issues/58141)
The "p1" suffix explicitly indicates WASI Preview 1, which helps distinguish it from the newer WASI Preview 2 (wasip2) and provides clarity about which version of the WASI specification is being targeted.
Also we already use `wasm32-unknown-wasip1` for Embedded WASI target, and having different names for Embedded and non-Embedded is confusing users.
- **Scope**: Narrow, only affects Wasm Swift SDK.
- **Original PRs**: https://github.com/swiftlang/swift/pull/83167
- **Risk**: Low, just a change to Wasm Swift SDK
- **Testing**: CI.
- **Reviewers**: @MaxDesiatov
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.
**Description**: This adds "task name" parameter to all task creating
functions.
This is done in a few ways, e.g. we can backdeploy this to 5.1 in APIs
which do not accept the `TaskExecutor` but it they do we provide a
version for 6.0+ etc. This was requested in the SE acceptable of this
proposal [Acceptance post
SE-0469](https://forums.swift.org/t/accepted-with-modifications-se-0469-task-naming/79438).
This moves all these declarations to gyb since going through them one by
one has become unmaintainable otherwise.
**Scope/Impact**: All task creation APIs now gain a new task name
parameter.
**Risk:** Medium, changes existing APIs rather than adding "even more
overloads" though this risk was discussed in the team and accepted. This
has a potential to be source breaking it someone used Task.init and
friends as function.
**Testing**: CI testing, source compatibility suite testing
**Reviewed by**:
**Original PR:**
- https://github.com/swiftlang/swift/pull/81107 build changes required
for this
- https://github.com/swiftlang/swift/pull/80984
**Radar:**
---------
Co-authored-by: Kuba Mracek <mracek@apple.com>
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.
- Scope: Disables optimizers passes in C++-only compiler for
bootstrapping purposes. Has no impact on full Swift compiler build.
- Risk: Low. This change has no impact in build environments where a
Swift compiler is available.
- Reviewers: @eeckstein
- Testing: PR testing -- Full PR testing fails if passes are
accidentally disabled.
Fixes: rdar://146357242
(cherry picked from commit bca1378fdb)
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).
Even with unified build, llvm is not always the top-level project but it
can be a part of a larger build. (e.g. [^1]) In that case,
`CMAKE_BINARY_DIR` is not the binary directory of llvm but the binary
directory of the top-level project. This patch fixes the issue by using
`LLVM_BINARY_DIR` instead.
[^1]: 9b4b907079/extensions/cxx_debugging/CMakeLists.txt (L105)
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.
Unified builds of compiler-rt together with LLVM failed for the Android SDKs. It got too complicated to redirect the way LLVM would configure the nested build-trees. Standalone builds slightly increase build time, but they turned out much simpler and we end up with less duplication of definitions.
This silences a warning that the MSVC compiler emits about unknown
pragmas. This helps clear up the build a small amount so real issues do
not get hidden.
`LLVM_DEFAULT_TARGET_TRIPLE` was previously set to
`aarch64-apple-darwin` for Darwin Arm64 platforms. The correct value
should be `arm64-apple-darwin`.
For C/CXX targets, sanitizer options are set by 'CMAKE_{C|CXX}_FLAGS' in
HandleLLVMComfig.cmake. However for Swift targets, they are set for each
target. That caused some mismatch issues. Instead set them globally for
Swift targets too.
rdar://142516855
* Revert "[Build] Fix swift_build_support tests."
This reverts commit fc2d1b3b23.
* Revert "[BuildSystem] Stop building for i386-watch-simulator (#77692)"
This reverts commit 1ab968d2b6.
This change can't be made without other issues fixed downstream first.
Enable support for libxml2 on Windows to allow `llvm-mt` to be usable.
This then allows us to use `llvm-mt` as the manifest tool when building
for Windows. Remove the then obsoleted workaround of `-D CMAKE_MT=mt`.
This reduces the dependency on the MSVC toolchain and paves the path to
enabling the use of the manifest tool in SPM.
However, to do this, we end up changing how amd64 is supported too.
Previously, I had tried to keep some meaningful separation between
platform spelling and LLVM spelling, but this is becoming more difficult
to meaningfully maintain.
Target specifications are trivially converted LLVM triples, and the
module files are looked up by LLVM triples. We can make sure that the
targets align, but then the Glibc to SwiftGlibc import breaks. That could
also be addressed, but then we get to a point where the targets set up
by build-script and referenced by cmake begin to misalign. There are
references in build-script-impl for a potential renaming site, but it's
not quite enough.
It's far simpler to give up and rename to LLVM spellings right at the
beginning. This does mean that this commit is less constrained to just
adding the necessary parts to enable arm64, but it should mean less
headaches overall from differing architecture spellings.
Windows has a strict limit on the file path, and use of extended names
for the build is not possible. Rather than hardcoding the location of
the early swift-driver build, allow the user to specify the path. If the
path is specified, we will attempt to copy `swift-driver` and
`swift-help` from that location. Adjust the code to account for the
build executable suffix. This should allow Windows to experiment with an
early swift-driver build.
