[SwiftBuild] Scope `--toolset` overrides to destination builds in SwiftPM

[kateinoigakukun]

Description

Follow-up from #773.

When SwiftPM forwards CLI --toolset inputs into SwiftBuild as unconditional SWIFT_SDK_TOOLSETS overrides, destination linker settings can leak into host-only builds such as macros and plugin tools. In JavaScriptKit, this showed up in Plugins/PackageToJS browser tests where BridgeJSMacros (a macOS host binary) was linked with wasm-only flags like --stack-first and -z stack-size=....

The minimum reproducer reduces this to a command plugin build of a wasm executable, App, that depends on a host-only macro executable, HelloMacros. The custom toolset intentionally injects a wasm-only linker option pair, -z stack-size=65536, so it is easy to see whether destination toolset settings are incorrectly applied to the host macro link.

With the 2026-06-12 Linux snapshot, the exact macOS fatal linker symptom does not occur because the Linux host linker accepts the -z option. However, the SwiftBuild host HelloMacros link command still receives the wasm-only -Xlinker -z -Xlinker stack-size=65536 flags, while the native/control build keeps the host macro link clean.

Expected behavior

Custom toolsets passed for Swift SDK builds should apply only to destination artifacts, not host tools built as part of the same graph.

In this reproducer:

• --build-system native should build the wasm App product and keep the wasm-only toolset flags on destination link steps.
• --build-system swiftbuild should also build the wasm App product without applying wasm-only toolset flags to the host HelloMacros link step.

Actual behavior

Using the requested 2026-06-12 Linux snapshot and swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm SDK:

• --build-system native exits 0 and reports succeeded: true and Build of product 'App' complete!.
• --build-system swiftbuild exits 0 on Linux, but the host HelloMacros link command still includes:

-Xlinker -z -Xlinker stack-size\=65536

On macOS affected toolchains, the same kind of host-link leakage fails with ld: unknown options: -z.

Steps to reproduce

Download the existing minimum reproducer zip from the issue comment:

https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/170c3566a0a21acf5c5ff14dac19282891ec7c76/774-toolset-scope.zip

Then run:

unzip 774-toolset-scope.zip
cd 774-toolset-scope

env \
  TOOLCHAIN=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 \
  TOOLCHAINS=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 \
  SWIFT_SDK_ID=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm \
  bash ./repro.sh

The script itself was not edited for the Linux verification. The environment overrides select the requested Linux Swift toolchain and SDK instead of the script's macOS/2026-05-27 defaults.

Swift Package Manager version/commit hash

Swift Package Manager - Swift 6.5.0-dev

Swift & OS version (output of swift --version ; uname -a)

Swift version 6.5-dev (LLVM 18d2bfb70c14d89, Swift c13d82e5987aecb)
Target: x86_64-unknown-linux-gnu
Build config: +assertions
Linux swift-dev.fugu.katei.dev 6.8.0-94-generic #96-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan  9 20:36:55 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

[kateinoigakukun]

Minimum reproducer zip is here:

• 774-toolset-scope.zip
• Direct zip URL: https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/170c3566a0a21acf5c5ff14dac19282891ec7c76/774-toolset-scope.zip
• Secret gist index: https://gist.github.com/kateinoigakukun/ba21c654a675032aa77906877c906e53

How to reproduce:

curl -L -O https://gist.githubusercontent.com/kateinoigakukun/ba21c654a675032aa77906877c906e53/raw/170c3566a0a21acf5c5ff14dac19282891ec7c76/774-toolset-scope.zip
unzip 774-toolset-scope.zip
cd 774-toolset-scope
./repro.sh

Environment used to validate these repros:

• Host: macOS 26.5.1 (arm64)
• Toolchain: ~/Library/Developer/Toolchains/swift-DEVELOPMENT-SNAPSHOT-2026-05-27-a.xctoolchain
• TOOLCHAINS=org.swift.64202605271a
• swift --version: Apple Swift version 6.5-dev (LLVM 8f81a64f6a8bcf6, Swift 4d0c97fa5b05711)
• Swift SDK: DEVELOPMENT-SNAPSHOT-2026-05-27-a-wasm32-unknown-wasip1
• Each repro.sh uses the explicit snapshot toolchain above, not the global swift on PATH.

Observed on this environment:

• --build-system native: plugin reported succeeded: true and Build of product 'App' complete!
• --build-system swiftbuild: failed while linking the host HelloMacros binary with ld: unknown options: -z

[kateinoigakukun]

Verification with the minimum reproducer from the gist zip:

• Workdir: /workspace/swiftpm-swiftbuild-issues/swb-jskit-774/774-toolset-scope
• Swift: /home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12/usr/bin/swift
• Swift version: Swift version 6.5-dev (LLVM 18d2bfb70c14d89, Swift c13d82e5987aecb), target x86_64-unknown-linux-gnu
• Swift SDK: swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm
• Reproducer script: original repro.sh; no script edits
• Invocation adaptation: passed TOOLCHAIN=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12, TOOLCHAINS=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12, and SWIFT_SDK_ID=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm so the macOS hardcoded default toolchain/SDK in the script would use the requested Linux snapshot and SDK.

Command run:

env TOOLCHAIN=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 TOOLCHAINS=/home/ubuntu/.local/share/swiftly/toolchains/main-snapshot-2026-06-12 SWIFT_SDK_ID=swift-DEVELOPMENT-SNAPSHOT-2026-06-12-a_wasm bash ./repro.sh > repro.log 2>&1

Result:

• Native/control path: exit code 0; succeeded: true; Build of product 'App' complete!
• SwiftBuild path: exit code 0; Build complete!
• The exact fatal symptom from the original macOS report, ld: unknown options: -z, did not occur under this Linux toolchain.
• However, swiftbuild.log still shows the host HelloMacros link using the wasm-only toolset flags:

Link HelloMacros (x86_64)
... -Xlinker -z -Xlinker stack-size\=65536 ...

Conclusion: the toolset-scope leak into the host macro link is still observable with --build-system swiftbuild, while native keeps the host macro link clean. The Linux linker accepts this particular -z flag, so the macOS-specific link failure does not occur here. Leaving this issue open.

Logs:

• repro.log
• native.log
• swiftbuild.log
• adaptation-notes.md

[kateinoigakukun]

Upstream issue: swiftlang/swift-package-manager#10222