This new flag makes it easy to build Swift cross-compilation toolchains, by
disabling cross-compilation of all host tools, like the Swift compiler and
various macros, building on prior pulls #38441 and #82163.
Also, add two class methods to the Testing macros product so it works with #83260.
specifically the change that makes the following possible on linux:
"* under Linux, do not cross compile LLVM when building for the host
architecture -- that will ensure that the compiler-rt build will use
the just built compiler and not the system one (which may not be
new enough for this purpose);"
Clang driver only passes arch-specific library paths as search paths
to the linker for WebAssembly targets but we were installing
libxml2.a under `<sysroot>/lib` without the multiarch triple. It led
to the linker not finding libxml2.a when importing FoundationXML
Cherry-pick of #83128, #82399, and #82878, merged as ea6ca2b5db, 0c4e56174b, and e34eb3331f respectively.
**Explanation**: Currently `test/CMakeLists.txt` can only set `SWIFT_LIT_ARGS` for all tests uniformly. This means that we can't have tests for Embedded Swift with a different set of `lit.py` arguments.
Also, create new `check-swift-embedded-wasi` target from `test/CMakeLists.txt`, tweak `lit.cfg` to support WASI Clang resource dir, exclude unsupported tests based on `CPU=wasm32` instead of `OS=wasi`.
**Scope**: Limited to Embedded Swift test suite.
**Risk**: Low, due to limited scope.
**Testing**: #82878 was incubated on `main` for 2 weeks, #82399 for 3 weeks with no disruption, #83128 merged this week, but enables all these tests on CI, which are consistently passing.
**Issue**: rdar://156585717
**Reviewer**: @bnbarham
- **Explanation**: Install static XCTest library and its Swift module files into Swift SDK for Wasm
- **Scope**: Narrow, only affects Wasm Swift SDK.
- **Original PRs**: https://github.com/swiftlang/swift/pull/83191
- **Risk**: Low, just a change to Wasm Swift SDK
- **Testing**: CI
- **Reviewers**: @MaxDesiatov
- **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
Cherry-pick of #82285, merged as 05204bdf63
**Explanation**: Include Swift Testing Foundation and libxml2 into the Swift SDK for WebAssembly
**Scope**: Limited to Swift SDK for Wasm
**Risk**: Low, due to limited scope. Changes were incubated on `main` for 2 weeks with no known issues. Swift Testing changes were incubated for more than a month.
**Testing**: Manual testing with Swift SDKs produced off `main`.
**Issue**: rdar://155865189
**Reviewer**: @MaxDesiatov
---------
Co-authored-by: Yuta Saito <kateinoigakukun@gmail.com>
We should eventually split these, but for now SWIFT_COMPILER_VERSION
matches SWIFT_TOOLCHAIN_VERSION when it's actually set. Just use it in
preference to SWIFT_TOOLCHAIN_VERSION.
(cherry picked from commit ec46a4f026)
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.
When the output is directly redirected, the output is re-encoded. This
is particularly important as `Write-PList` uses `Invoke-Program` to
invoke `python.exe` to write the plist. However, because it is writing
to a file, while the output from Python is in UTF-8, the redirection
re-encodes the output to UTF16LE (BOM). Adjust the invocation to use
PS7+ `2|` and pipe both stdout and stderr as appropriate into files with
UTF-8 encoding restoring the encoding for the file.
- **Explanation**: Build wasmkit, a new toolchain executable, as universal binary on macOS using SwiftPM --arch flags. (Cherry picked from commit 6530236)
- **Scope**: WasmKit is new, and users targeting Wasm (and preferring WasmKit over other Wasm runtimes) might be few. WasmKit can be invoked directly by users and indirectly via `swift run` when using the official Swift SDKs for Wasm.
- **Issues**: Resolves#82390
- **Original PRs**: #82393
- **Risk**: The new configuration only affects macOS targets. The binary is output to a new location, but the code already introspects the location correctly. The bug and fix impacts users of WasmKit binary newly added to toolchain, directly and via `swift run`. Risk of no-fix: The Swift.org wasm "Getting Started" [1] refers explicitly to this (unreleased) 6.2 toolchain WasmKit binary. Without this fix, users on Apple Silicon following those instructions get an obscure "bad CPU" error because it is built only for the host x86_64 arch.
- **Testing**: @kateinoigakukun verified WasmKit is universal after change in `main`. To verify, run shell `file usr/bin/wasmkit` and verify outputs include x86_64 and arm64 arch. An outstanding question is whether to add a check that toolchain executables are universal binaries on macOS. Currently they are, except for `docc`.
- **Reviewers**: @kateinoigakukun
[1] https://www.swift.org/documentation/articles/wasm-getting-started.html
llvm-symbolizer is critical to ASAN/LSAN properly reading and applying
allowlists and suppressions. Without properly symbolized backtraces,
the tools cannot match stack traces to suppression lists, leading to
false negatives in leak detection and other issues.
Ensure that it's installed in the toolchain presets.
This is useful when building cross-compilation toolchains where you want
the stdlib and corelibs cross-compiled but don't want the Swift compiler
cross-compiled too with `--cross-compile-hosts`.
Passes the value of the environment variable `TOOLCHAIN_VERSION` through
to Swift's `SWIFT_TOOLCHAIN_VERSION` for use in eg.
`-print-target-info` (and some day, `--version`).
(cherry picked from commit 3982ebbbb3)
