…ruct (swiftwasm#800)

…ics-import

BridgeJS: Support generic functions on imported JS APIs

An imported optional whose payload is stack-only ([T]?, [String: V]?,
@js struct?) used a hybrid convention: the isSome flag crossed as a wasm
i32 parameter while the payload was conditionally pushed onto the shared
stacks. Optional returns and optional array elements of the same types
already travel entirely on the stacks: payload first, then a 0/1 flag on
the i32 stack.

This lowers those parameters the same way. The Swift thunk pushes the
payload (if some) followed by the flag, the wasm signature carries no
argument for the parameter, and the JS handler pops the flag before
conditionally lifting the payload, through the same fragment already
used for optional returns and elements.

The hybrid shape was the last parameter category that both passed a wasm
argument and pushed stack data, which is what enabled the argument
transposition fixed in swiftwasm#794. Every stack-touching parameter is now
flagless and reverse-ordered, matching returns and elements. All other
optional parameter ABIs (scalars, strings, JSObject, closures, enums,
heap objects) are unchanged.

…stack-flag

BridgeJS: Lower imported optional stack parameters fully on the stack

BridgeJS: Allow extensions to contain types

…fied-types

…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.