NodetteHQ/PureXML
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

fix(wasm): fail check-wasm with an actionable message on a toolchain without the wasm backend (#365)

Browse Source 
When swiftly is absent, check-wasm.sh fell back to the active `swift`. The Xcode-bundled
Apple toolchain has no WebAssembly LLVM codegen backend, so a wasm cross-compile through
it does not fail cleanly: it aborts deep inside LLVM (clang module build, "No available
targets are compatible with triple wasm32-...") with a multi-megabyte stack dump that
reads like a code bug. The SDK-presence check passed (the SDK is installed) and the build
crashed anyway, so the real cause, the wrong host toolchain, was invisible.

Detect it up front and exit 2 with an actionable message. Discriminate by the compiler's
self-reported build tag, not its path: both toolchains print "Apple Swift version X", but
the Xcode/Apple build tags it "(swiftlang-...)" while a swift.org toolchain tags it
"(swift-...-RELEASE/SNAPSHOT)". The self-report is authoritative however `swift` is
symlinked or shimmed, which a path-string match would miss. `swift -print-target-info
-target wasm32-...` is not a usable probe: it succeeds even without the backend, because
the frontend knows the triple and only codegen is missing.
This commit is contained in:
Mihaela Mihaljevic 2026-06-28 05:09:20 +02:00 committed by GitHub
parent 5d38f0c82f
commit 9e40278218
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 26 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
scripts/check-wasm.sh
View File

@ -19,6 +19,32 @@ if ! swift_command sdk list | grep -qx "$SDK_ID"; then
exit 2
fi
# The open-source swift.org toolchain ships the WebAssembly codegen backend; the
# Xcode-bundled Apple toolchain does not. Cross-compiling to wasm through the Xcode
# toolchain therefore aborts deep inside LLVM ("No available targets are compatible
# with triple wasm32-...") with a multi-megabyte stack dump that looks like a code
# bug but is purely a wrong-toolchain setup. When we are not going through swiftly,
# detect that case up front and fail with an actionable message instead.
#
# Discriminate by the compiler's self-reported build tag, not its path: both
# toolchains print "Apple Swift version X", but the Xcode/Apple build tags it
# "(swiftlang-...)" while a swift.org toolchain tags it "(swift-...-RELEASE/SNAPSHOT)".
# The self-report is authoritative however `swift` is symlinked or shimmed (a path
# check misses a /usr/local/bin/swift that links into Xcode). 'swift
# -print-target-info -target wasm32-...' is NOT a usable probe: it succeeds even
# without the backend, because the frontend knows the triple and only codegen is gone.
if ! command -v swiftly >/dev/null 2>&1; then
if swift --version 2>/dev/null | grep -q '(swiftlang-'; then
echo "wasm: the active Swift is the Xcode/Apple toolchain, which has no WebAssembly" >&2
echo "wasm: codegen backend, so a wasm cross-compile cannot work here and would crash" >&2
echo "wasm: inside LLVM rather than fail cleanly." >&2
echo "wasm: install swiftly and the swift.org toolchain that matches '$SWIFT_SELECTOR'" >&2
echo "wasm: (it ships the wasm backend), or put a swift.org toolchain first as 'swift'," >&2
echo "wasm: then re-run. See https://www.swift.org/install/ and https://swiftwasm.org." >&2
exit 2
fi
fi
swift_command build --swift-sdk "$SDK_ID"
swift_command build -c release --swift-sdk "$SDK_ID"