GeezerVison

Merge pull request swiftwasm#811 from PassiveLogic/kr/package-to-js-u…

…wasi

PackageToJS: Add selectable UWASI runtime

PackageToJS: Derive WASI and shared memory support from wasm imports (s…

…wiftwasm#807)

* PackageToJS: Derive WASI and shared memory support from wasm imports

The SwiftBuild backend's build directory doesn't encode the target triple, so
detect the traits derived from it by parsing the imports of the product binary
instead. The imports are now parsed as a part of the packaging build graph.

* Avoid `import var Foundation.stderr`

```
$ echo "@preconcurrency import var Foundation.stderr" | swiftly run +main-snapshot-2026-08-11 swiftc  - -o /dev/null
<stdin>:1:28: error: ambiguous name 'stderr' in module 'Foundation'
1 | @preconcurrency import var Foundation.stderr
  |                            `- error: ambiguous name 'stderr' in module 'Foundation'
2 |

Glibc.stderr:1:32: note: found this candidate
1 | nonisolated(unsafe) public var stderr: UnsafeMutablePointer<FILE>! { get }
  |                                `- note: found this candidate

/usr/include/stdio.h:151:14: note: found this candidate
149 | extern FILE *stdin;               /* Standard input stream.  */
150 | extern FILE *stdout;              /* Standard output stream.  */
151 | extern FILE *stderr;              /* Standard error output stream.  */
    |              `- note: found this candidate
152 | /* C89/C99 say they're macros.  Make them happy.  */
153 | #define stdin stdin
```

swiftlang/swift#89891

* CI: Install Swift toolchain preserving its usr/bin layout

Flattening the tarball into /usr/local makes SwiftPM derive a bogus
toolchain root, so the swiftbuild build system cannot find swiftc.

* PackageToJS: Record every import kind while parsing wasm imports

Only memory imports were collected, so `WasmFeatures.isWASI` never saw
`wasi_snapshot_preview1` and the generated node.js dropped the WASI import
while still constructing a WASI instance.

* PackageToJS: run per-target test runners under the swiftbuild build system

`swift package js test` assumed the native build system's single combined
`<Package>PackageTests` binary: it looked for one `.wasm`/`.xctest` under
`.build/<config>/`, packaged it, and ran it.

SwiftBuild produces no combined test binary. It emits one
`<TestTarget>-test-runner.wasm` per test target under `.build/out/Products/`,
plus an aggregate target that only orchestrates building them, so the old
lookup failed with "Failed to find 'JavaScriptKitPackageTests.wasm'".

(cherry picked from commit c12c7e9)

* Install the JS event loop executor in async test targets

Because SwiftBuild mode produces a linked executable for each test
target.

(cherry picked from commit 0a1f926)

* BridgeJS: Skip type handle registration for unlinked modules

`js test` generates the glue from every test target's skeletons, but the
SwiftBuild build system links one binary per test target, so the eager
registration hit a missing export.

* PackageToJS: Share the linked JS modules with the aggregated glue

The per-runner `bridge-js.js` copied to the base output directory for test
preludes imports its JavaScript modules relative to itself, so copy the
`bridge-js-modules` directory next to it.

* BridgeJS: Require the imports object for static-only imported types

An imported type looked up from `getImports` contributes its static methods
too, but only a constructor marked the imports object as needed, so the glue
referenced an undeclared `imports`.

* PackageToJS: Generate each test bundle's glue from what its binary links in

`js test` generated the glue from every test target's skeletons and handed
the same copy to each SwiftBuild per-target runner, which described exports
those binaries don't have. Package the aggregated glue once into the shared
base directory, where preludes import it by a fixed path, and give each
runner glue scoped to the target it links in.

This supersedes the registration guard in the JS code generator.

Merge pull request swiftwasm#798 from swiftwasm/yt/fix-struct-closure…

…-param

BridgeJS: Unify @js struct parameter lowering onto the stack ABI

BridgeJS: import from external ECMAScript modules, and split snippet …

…origins (swiftwasm#795)

* BridgeJS: support importing from external ECMAScript modules

Extend `from: .module(...)` to accept bare specifiers like `node:path` or an npm package,
add `jsName: .default` for default exports, and emit named imports so a wrong export name
now fails at module-link time instead of at call time.

* BridgeJS: fix named-import regressions found in review

Do not require a module export for a wrapper-only `@JSClass`, since a named import is a
link-time requirement and nothing looks that name up; accept `jsName: nil` and the explicit
`.name(...)` spelling; and validate the tagged `from` form like the plain-string form.

* BridgeJS: split snippet and external module import origins

Use `from: .snippet("/my-file.js")` for a JavaScript file shipped with the Swift target and
`from: .module("node:path")` for an external module, so each keeps its own validation and
each mistaken form points at the other. The skeleton encoding is unchanged.

* BridgeJS: tag both snippet and module origins in the skeleton

Encode `.snippet` as `{"kind":"snippet","path":...}` alongside the existing tagged module
form, so the JSON mirrors the Swift cases and a snippet path can no longer encode into a
shape that fails to decode.

Fix `JavaScriptEventLoop` for Embedded Swift in `main` toolchain snap…

…shots (swiftwasm#784)

Merge pull request swiftwasm#750 from wfltaylor/js-as

BridgeJS: Export types using a separate JS representation

Merge pull request swiftwasm#768 from PassiveLogic/fix/bridgejs-point…

…er-limitations

BridgeJS: Normalize wasm pointer offsets in JS

Fix error descriptions Embedded Swift compatibility (swiftwasm#759)

The BridgeJS generator emits `JSError(message: String(describing: error))` for throwing `@JS` exports, but `String.init(describing:)` is unavailable in Embedded Swift, so embedded Wasm builds of any package with a throwing export fail. The caught error is statically a `JSException` with a stored `description`, so the generated glue now uses `error.description` for identical output. Snapshots regenerated.

Merge pull request swiftwasm#754 from PassiveLogic/kr/fix-optional-js…

…class-param

BridgeJS: Support optional @jsclass as exported function parameters

BridgeJS: Optimize numeric array transfer with bulk TypedArray copy (s…

…wiftwasm#745)