Add `wasm32-unknown-emscripten` triple support by MaxDesiatov · Pull Request #2105 · swiftlang/swift-driver

MaxDesiatov · 2026-03-16T16:37:56Z

One of the necessary steps for implementing the Emscripten pitch: https://forums.swift.org/t/pitch-emscripten-target-support-for-swift/85310.

Depends on swiftlang/swift#88732

MaxDesiatov · 2026-04-20T16:41:52Z

@swift-ci test

jakepetroules · 2026-04-21T08:13:06Z

Can you also add support for this platform in Swift Build's SWBWebAssembly plugin?

MaxDesiatov · 2026-04-22T15:00:11Z

Can you also add support for this platform in Swift Build's SWBWebAssembly plugin?

Done in swiftlang/swift-build#1335

MaxDesiatov · 2026-04-28T15:29:26Z

swiftlang/swift#87797
@swift-ci test

MaxDesiatov · 2026-04-30T09:24:58Z

@swift-ci test

MaxDesiatov · 2026-05-11T16:03:55Z

@swift-ci test

MaxDesiatov · 2026-05-11T16:04:12Z

@swift-ci test windows

artemcm · 2026-05-11T18:06:44Z


  public let dummyForTestingObjectFormat = Triple.ObjectFormat.wasm

+  public var targetTriple: Triple?


Could we parameterize makeLinkerOutputFilename instead? Even though it means updating unrelated toolchains, I'd rather we thread the triple to the decision point where we need it, instead of this kind of mutable state that's post-hoc initialized.

Creating a separate EmscriptenToolchain should address this as well.

artemcm · 2026-05-11T18:08:12Z

          components: "embedded", targetTriple.triple
        )
-        commandLine.append(.flag("-Xlinker"))
+        if !isEmscripten {


I don't know if I have a better suggestion, but it feels a bit unwieldy to special case things like this. Would there be too much duplication if we factor out the emcc code path out of here?

Addressed by creating separate EmscriptenToolchain.

…chain`

MaxDesiatov · 2026-05-12T16:01:08Z

@swift-ci test

MaxDesiatov · 2026-05-12T16:02:20Z

@swift-ci test windows

kateinoigakukun · 2026-05-12T16:27:31Z

+        commandLine.appendFlag(linkerOpt.argument.asSingle)
+      }
+      // `-Xemcc-linker` passes arguments directly to `emcc`.
+      try commandLine.appendAllArguments(.XemccLinker, from: &parsedOptions)


If we pass -Xemcc-linker values to emcc, then I'm wondering if we really need a separate option name for emcc. Can't we just use -Xclang-linker? We can treat it just like "X flag for linker driver, not the linker itself" rather than strictly treating it only for "clang linker driver". emcc is meant to be used as drop-in-replacement as clang command, so this model should work I believe. Otherwise the build invoker has to switch the option based on if a target is emscripten or not, which is something I'm not a big fan of.

It's not a drop-in replacement unfortunately, flags and options it supports differ substantially. I think keeping -Xclang-linker for it would be very confusing, as very few of the existing options work and require explicit updates. I'm totally fine with introducing -Xlinker-driver separately though.

It's not a drop-in replacement unfortunately, flags and options it supports differ substantially.

Oh, really. I know many options specific to emcc but don't know much about clang options not working for emcc. Do you have examples?

I know of at least 3 cases that break or warn:

-resource-dir PATH and --sysroot PATH: emcc has a silent flag-drop: it swallows the flag word but lets the path leak as a positional input leading to wasm-ld: error: cannot open PATH: Is a directory. Same bug hits -B PATH. Joined forms work.

-nostdlib: accepted but semantically incompatible (emcc's runtime needs symbols -nostdlib drops)

-Wl,-z,max-page-size=16384: wasm-ld warns and no-ops

As for the asymmetry: emcc-only flags like -sENVIRONMENT=shell, --shell-file= are hard errors under clang (unknown argument).

artemcm · 2026-05-13T09:27:56Z

  public static let Wwarning: Option = Option("-Wwarning", .separate, attributes: [.helpHidden, .frontend], metaVar: "<diagnostic_group>", helpText: "Treat this warning group as warning", group: .warningTreating)
  public static let Xcc: Option = Option("-Xcc", .separate, attributes: [.frontend, .synthesizeInterface], metaVar: "<arg>", helpText: "Pass <arg> to the C/C++/Objective-C compiler")
  public static let XclangLinker: Option = Option("-Xclang-linker", .separate, attributes: [.helpHidden], metaVar: "<arg>", helpText: "Pass <arg> to Clang when it is used for linking.")
+  public static let XemccLinker: Option = Option("-Xemcc-linker", .separate, attributes: [.helpHidden], metaVar: "<arg>", helpText: "Pass <arg> to emcc when it is used for linking.")


A reminder to follow the process here:
https://github.com/swiftlang/swift-driver#rebuilding-optionsswift

artemcm

Much cleaner, thanks!

artemcm · 2026-05-13T09:28:45Z

+      )
+
+      // `emcc` supports `-Xlinker` for passing flags to `wasm-ld`, but
+      // `-Xclang-linker` is `clang`-specific and must not be forwarded.


Should we warn when -Xclang-linker is used and we are on the emcc code path, instead of dropping them silently?

It does emit a working in EmscriptenToolchain validation function, I've updated this comment to mention that in #2136

artemcm · 2026-05-13T09:30:08Z

+
+    // Delegate to Clang for sanitizers. It will figure out the correct linker
+    // options.
+    if linkerOutputType == .executable && !sanitizers.isEmpty {


From what I can tell, in the code as-is, linkerOutputType == .executable is always going to be true. Do we think that can change in the future? If not, do we still need linkerOutputType here?

Addressed in #2136

MaxDesiatov · 2026-05-13T09:32:36Z

Ah, sorry about the auto-merge that I forgot to disable, I'll submit a follow up PR!

MaxDesiatov mentioned this pull request Apr 22, 2026

Add wasm32-unknown-emscripten build system and stdlib support swiftlang/swift#87797

Draft

MaxDesiatov marked this pull request as ready for review April 28, 2026 15:22

MaxDesiatov requested a review from a team as a code owner April 28, 2026 15:22

MaxDesiatov requested a review from kateinoigakukun April 28, 2026 15:22

MaxDesiatov added 4 commits May 11, 2026 16:42

Add support for Emscripten triples

aae2d47

Fix Emscripten linking issues

40e0841

Add support for -Xemcc-linker

36fbaa9

Add emcc as a cached tool

d8ce09e

MaxDesiatov force-pushed the maxd/emscripten-support branch from c232995 to d8ce09e Compare May 11, 2026 16:03

MaxDesiatov requested review from DougGregor, artemcm, cachemeifyoucan, compnerd and owenv as code owners May 11, 2026 16:03

MaxDesiatov enabled auto-merge May 11, 2026 16:04

artemcm reviewed May 11, 2026

View reviewed changes

MaxDesiatov added 2 commits May 12, 2026 16:40

Split WebAssemblyToolchain into WASIToolchain and `EmscriptenTool…

a9244fc

…chain`

Clean up formatting and comments

9e71ca6

MaxDesiatov requested a review from artemcm May 12, 2026 16:02

kateinoigakukun reviewed May 12, 2026

View reviewed changes

MaxDesiatov requested a review from kateinoigakukun May 13, 2026 09:24

artemcm reviewed May 13, 2026

View reviewed changes

artemcm approved these changes May 13, 2026

View reviewed changes

MaxDesiatov merged commit f71edf5 into main May 13, 2026
22 of 26 checks passed

MaxDesiatov mentioned this pull request May 13, 2026

EmscriptenToolchain: clean up comments and linkerOutputType handling #2136

Open

MaxDesiatov deleted the maxd/emscripten-support branch May 13, 2026 11:43


		public let dummyForTestingObjectFormat = Triple.ObjectFormat.wasm

		public var targetTriple: Triple?

Conversation

MaxDesiatov commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

MaxDesiatov commented Apr 20, 2026

Uh oh!

jakepetroules commented Apr 21, 2026

Uh oh!

MaxDesiatov commented Apr 22, 2026

Uh oh!

MaxDesiatov commented Apr 28, 2026

Uh oh!

MaxDesiatov commented Apr 30, 2026

Uh oh!

MaxDesiatov commented May 11, 2026

Uh oh!

MaxDesiatov commented May 11, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

MaxDesiatov commented May 12, 2026

Uh oh!

MaxDesiatov commented May 12, 2026

Uh oh!

kateinoigakukun May 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

artemcm left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

MaxDesiatov commented May 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

MaxDesiatov commented Mar 16, 2026 •

edited

Loading

kateinoigakukun May 12, 2026 •

edited

Loading