Support cross-compiling to WebAssembly and Android with Swift SDKs

[AttilaTheFun]

Summary

Adds first-class support for cross-compiling swift_library / swift_binary to WebAssembly (wasm32-unknown-wasip1) and Android (aarch64 / x86_64) using the official Swift SDK artifact bundles published by swift.org -- the same bundles swift sdk install consumes.

A target is selected purely by --platforms and produces the artifact each ecosystem actually consumes: a WASI executable or reactor module, or an Android executable or shared library. This builds directly on the existing hermetic standalone-toolchain infrastructure (the swift module extension and the embedded toolchain shape) rather than introducing a parallel mechanism -- no custom rules, no manual swiftc plumbing.

Usage

swift = use_extension("@rules_swift//swift:extensions.bzl", "swift")
swift.toolchain(name = "swift_toolchain", swift_version = "6.3.2")
swift.wasm_sdk(toolchain_name = "swift_toolchain")
swift.android_sdk(toolchain_name = "swift_toolchain")  # api_level = 28 by default

register_toolchains(
    "@swift_toolchain//:swift_toolchain_wasm32_xcode",
    "@swift_toolchain//:cc_toolchain_wasm32_xcode",
    "@swift_toolchain//:swift_toolchain_android_aarch64_xcode",
    "@swift_toolchain//:cc_toolchain_android_aarch64_xcode",
    # ... per host platform / architecture
)

Then build any swift_library / swift_binary with a platform carrying @platforms//os:wasi + cpu:wasm32 or @platforms//os:android + cpu:{aarch64,x86_64}:

# A WASI reactor (no `main`; exports functions for a JS host) or an Android
# JNI shared library -- same attribute as cc_binary's `linkshared`:
swift_binary(name = "App", srcs = [...], linkshared = True)

See the new section in doc/standalone_toolchain.md and examples/cross_compilation/.

Output kinds

swift_binary produces the conventional artifact for each platform:

linkshared	wasm	Android	host (unchanged)
False (default)	WASI command module (.wasm, has _start/main)	executable	executable
True	WASI reactor (.wasm, no main, -mexec-model=reactor)	shared library (lib<name>.so)	shared library (.so/.dylib)

A wasm reactor / shared library has no main; it exports functions for a host to call (linkopts = ["-Xlinker", "--export=<sym>"]). On wasm, linkshared maps to the reactor execution model, not a -shared dynamic library.

Design

• One Swift release, everywhere. A Swift SDK only works with the host compiler from the same release tag (the module format is unstable across versions), so the SDK tags reference a swift.toolchain tag by name and derive the version, URLs, and bundled checksums (swift_sdk_releases.bzl) from it.
• Per-(host, target) repositories. Each generated repo pairs one SDK with one standalone host toolchain and defines a swift_toolchain (compile: -sdk, -resource-dir, clang-importer builtin headers) plus a rules_cc cc_toolchain for linking -- the host toolchain's clang for wasm, the NDK's clang for Android. Everything is fetched lazily: host-only builds fetch nothing new, and wasm-only builds do not download the NDK.
• Static Swift runtime, linked the way swiftc does. The toolchains link the SDK's static stdlib, mirroring the flags swiftc uses with these SDKs (static-executable-args.lnk / static-stdlib-args.lnk). For wasm this includes placing linear-memory data and the indirect function table at the same bases swiftc passes to wasm-ld (--global-base=4096, --table-base=4096); --table-base in particular is required for correctness -- optimized (-O) Swift relies on the indirect function table starting where the runtime/codegen expects it, and without it generic-metadata instantiation faults at runtime (see the dedicated commit). Android binaries use the NDK's libc++_shared.so (exposed by the NDK repo as :libcxx_shared_{arch} for app packaging) and a 16 KiB max page size as required by Android 15+.
• New generic swift_toolchain attributes. linkopts / linker_inputs let a toolchain supply the runtime link flags and inputs explicitly, replacing the hardcoded per-OS defaults that don't apply to SDK-provided runtimes. The runtime start object (swiftrt.o) is modeled as an executable-only input so reactor / shared-library links omit it automatically.
• swift.no_entry_point_rename feature. wasm-ld has no --defsym, so the entry-point rename that swift_binary performs (to allow linking binaries into tests) cannot be aliased back to the symbol wasi-libc's startup expects; the wasm toolchain opts out of the rename instead.
• No merged NDK sysroot. Because linking goes through the CC toolchain rather than swiftc -emit-executable, the Swift driver's requirement that swiftrt.o live inside the -sdk sysroot never applies; the start object is passed explicitly, and the plain NDK sysroot is used for compilation.

Testing

• examples/cross_compilation/ builds a shared swift_library (Greeter) reused by every entry point, plus a wasm reactor (Reactor.wasm), a browser web app embedding it (web_app -- index.html + a Node verify.mjs headless check, see web/README.md), and an Android JNI shared library (libSwiftJNI.so) with a documented Kotlin packaging recipe (android_app/). A new dedicated CI task builds all of these on macOS (they're tagged manual because they fetch the SDK bundles / NDK, so they were previously skipped by the //examples/... wildcard).
• The wasm reactor runs under wasmtime and in the browser, returning the greeting Swift wrote into linear memory ("Hello from Swift, WebAssembly!").
• The Android shared library is a well-formed ET_DYN AArch64 object (verified JNI symbols, liblog/libc++_shared NEEDED entries, and 16 KiB LOAD alignment with llvm-readelf); it loads on-device with no UnsatisfiedLinkError.
• Validated end-to-end against a real consumer: a full SwiftUI-subset application cross-compiled -- unchanged source -- to wasm and Android (alongside the real-SwiftUI Apple build via a recent rules_apple, which coexists with this rules_swift). All targets build and the app boots and renders in the browser in both fastbuild and -c opt. The -O metadata crash fixed by the --table-base commit was found and reproduced through this consumer.
• bazel test //test/... //examples/... //doc/...: identical results to upstream main on the same machine (the only failures are pre-existing local XCTest/Xcode-version environment issues, byte-identical failure sets verified against a pristine main worktree).
• bazel run //doc:gazelle is a no-op; buildifier clean.
• The dev MODULE.bazel toolchain was bumped 6.3 → 6.3.2 (the release the SDK checksums are bundled for); all examples including examples/embedded build with it.

Windows host support

This branch also takes building Swift natively on Windows (host toolchain + MSVC, orthogonal to the Swift-SDK cross-compilation above) from "scaffolding present but never exercised in CI" to verified end-to-end on a real Windows 11 host (Swift 6.3.2 for Windows + Visual Studio 2022 / MSVC 14.44, Bazel 9.1.1). swift_binary, swift_library, swift_binary(linkshared = True) → .dll, and swift_test all build and run. Verifying the WINDOWS.md checklist surfaced a mix of bit-rot and genuinely missing Windows code paths; the fixes, by area:

• Autoconfiguration (swift_autoconfiguration.bzl): skip the Microsoft Store python3.exe execution-alias stub and probe for a working interpreter; normalize SDKROOT (forward slashes, no trailing separator) so it is valid inside the Python snippet that reads XCTEST_VERSION — both previously left xctest_version empty; detect the host CPU instead of hardcoding x86_64.
• Toolchain (swift_toolchain.bzl): don't require a clang CC toolchain on Windows (MSVC msvc-cl is expected); use MSVC /ALTERNATENAME instead of GNU ld's --defsym for the entry-point alias; emit the -msvc target-triple environment so swift-symbolgraph-extract can load *-windows-msvc modules; pass the XCTest include paths to the symbol-graph-extract action; suppress the benign LNK4217 that statically linking dllimport symbols produces; understand the aarch64 library / bin64a layout.
• swift_test / test discovery: port tools/test_observer to Windows — SRWLOCK locking, GetProcAddress-based swift-testing entry-point lookup, and a swift-corelibs XCTest runner shared with Linux (LinuxXCTestRunner → SwiftCorelibsXCTestRunner); run the discovery tool with the Swift runtime on PATH.
• Worker / general: make the persistent worker's filesystem operations long-path (\\?\) aware (the _swift_incremental storage area exceeds MAX_PATH); sanitize spaces out of derived object paths so the MSVC archiver/linker response files parse (e.g. swift-argument-parser's Parsable Properties/); disable worker sandboxing on Windows (build:windows in .bazelrc).

A new //examples/xplatform/shared_library (linkshared → .dll) example is added, and a Windows CI task that builds the examples and runs the xctest test is re-enabled — the Swift-install prologue / BazelCI Windows image provisioning is the one piece not validated on a local host. aarch64 Windows is implemented (host-CPU detection + a registered toolchain) but unverified for lack of arm64 hardware. See WINDOWS.md for the full status and prerequisites.

Notes for review

• CI cost. The new cross-compilation CI task downloads the Swift SDK bundles (~400 MB) and the Android NDK (~600 MB), on top of the standalone toolchain the embedded example already fetches. It is a single dedicated macOS task (build-only) so it can be tuned or split independently; Linux coverage can be added the same way if desired.
• The SDK's armv7 resources are present but not wired up; ANDROID_ARCHS can be extended on demand.
• The register_toolchains list is currently explicit per (host, target); auto-registration / an :all convenience could be a follow-up (the dev MODULE.bazel notes why :all is ambiguous across Linux distros today).

[keith]

This is great, some high level comments:

• can you split this up into multiple PRs? as is there are a lot of separate things in here, linkshared support, windows support, android support, and wasm support
• can we use @androidndk instead of downloading it ourselves? i imagine for the most likely users of this having to maintain the version bumps and stuff between those 2 versions would be a bit annoying
• can you edit down the LLM comments / docs to what you think is useful long term
• would it be possible to avoid some of the wasm specific stuff in swift_binary? i guess ideally that stuff would live in the toolchain somehow?

[keith]

I think disabling this is probably the wrong one, we might want to disable the xcode specific one? or i believe there was one added for embedded stuff specifically to say it doesn't support developer dir that maybe we should use instead?

[AttilaTheFun]

thanks @keith ! yes I can try to split this up, though Github doesn't handle cross-repo stacked PRs well. we might have to land them one at a time and I can rebase.

I have broken them up like this:

main ─┬─ linkshared
└─ Swift SDK framework
├─ WebAssembly
├─ Android
└─ Windows host

#1820
#1821
#1817
#1818
#1819

[AttilaTheFun]

Superseded — this was split into #1817 (wasm), #1818 (Android), #1819 (Windows), #1820 (linkshared), and #1821 (Swift SDK framework), all now merged. Thanks for the reviews!