BridgeJS: Support generic functions on exported Swift APIs

[krodak]

Overview

Export half of generic function support (swiftwasm#398), on top of the import half (swiftwasm#799) and @JS protocol refinement with constrained imports (swiftwasm#815). An exported @JS function or method can take a type parameter, and the JavaScript caller selects the concrete type with a BridgeTypes token:

@JS public func store<T: BridgedSwiftGenericBridgeable & GraphNode>(_ node: T) -> T { node }

import { BridgeTypes } from "./bridge-js.js";
const b = exports.store({ id: "b1", floors: 3 }, BridgeTypes.Building);   // store<T extends GraphNode>

T may be any bridgeable primitive, String, JSValue, a @JS struct, final class, or enum, or a @JS protocol that inherits BridgedSwiftGenericBridgeable (its token selects the generated JavaScript-backed wrapper), bare or as [T], T?, [String: T]. Generics work on top-level functions and on instance and static methods of @JS classes, structs, and enums. Values cross on the existing stack ABI; the only addition on the wire is a trailing i32 type ID per generic parameter.

1. Type recovery. The type ID is the address of the type's BridgeJSTypeHandle, so the concrete @_expose thunk recovers the type with Unmanaged.fromOpaque and reifies T through an opened existential (a nested chain for multiple parameters). No per-module registry. Generic thunks always hoist stack-using arguments so pops run in reverse declaration order ahead of a struct self pop embedded in the callee. Excluded under Embedded Swift (needs the handle's metatype).

2. @JS protocol constraints on exports. <T: BridgedSwiftGenericBridgeable & P1 & P2> (or <T: P> when P inherits the bound), reusing swiftwasm#815's constraint parsing. Unlike imports, the Swift compiler cannot check a JavaScript caller, so the constraint is enforced at the boundary: the link layer records every type's @JS protocol conformances (declared inline, in an extension, or in an extension on a dependency's type), closes them over protocol refinement, and the wrapper validates the token against the constraint before lowering anything. A non-conforming token throws a catchable TypeError and the value stack stays balanced. The generated Swift generic clause keeps qualified spellings (GraphKit.Node); the d.ts carries T extends P1 & P2. Same-named @JS protocols across linked modules fail the link, mirroring the token rule for types.

3. throws(JSException) generic exports. Same side-channel convention as concrete throwing exports; the wrapper rethrows before lifting. async generic exports are rejected with a diagnostic: promise settlement is per-type today and a codec-driven settlement path is a separate ABI addition.

4. Tokens are branded. BridgeType<T> uses a unique symbol brand, so a raw "Int" does not satisfy BridgeType<number>; a call-site fixture under check:bridgejs-dts pins that, T inference, and constraint rejection. Namespaced types use their ABI name as the token (BridgeTypes.API_Building).

Unsupported forms produce build-time diagnostics: async, where clauses, unused generic parameters, concrete non-Void returns, nested wrappings, generic initializers, default parameter values on generic exports, and generic requirements on @JS protocols.

Test plan

• Codegen and link snapshots for every thunk shape, including generic methods on each owning construct, renamed and namespaced members, throwing generics, constraint compositions, and bridgeable-protocol tokens
• Diagnostics suites, including qualified external constraints and legacy skeleton decoding
• WASM runtime round-trips of every bridgeable type, constrained round-trips including refinement, the unknown-token and non-conforming-token TypeError paths with a follow-up call proving stack balance, and a thrown generic call leaving the stacks balanced
• Root BridgeJSTool build, Examples/Embedded, check:bridgejs-dts, and bridge-js-generate.sh drift check pass; the upstream swiftbuild lane passes on swift-DEVELOPMENT-SNAPSHOT-2026-08-11-a

Tracks BridgeJS: Generic exports PR with @JS protocol constraints.