[NFC] BridgeJS: Remove remaining explicit captures from enum/struct helpers

…rations in TypeScript (#592)

[NFC] BridgeJS: Make Stack ABI storage direction agnostic

* Doc comments from .d.ts JSDoc now flow into generated Swift DocC output.

- Added JSDoc parsing (description/@param/@returns) and DocC emission for callable/typed declarations, including classes/interfaces/enums, in `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/src/processor.js`, with guards to only read param/return tags on callable nodes.
- Added a documented fixture to cover the new behavior and updated the Vitest snapshot (`Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/fixtures/Documentation.d.ts`, `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/__snapshots__/ts2swift.test.js.snap`).

Tests:
- `npm test -- -u` (Plugins/BridgeJS/Sources/TS2Swift/JavaScript)

Next steps: optionally run `swift test --package-path ./Plugins/BridgeJS` to keep the Swift-side suite green.

* Added richer WebIDL-derived doc coverage using the bridgejs-development skill: new fixtures model lib.dom-style comments (MDN reference blocks, @param text) and updated Vitest snapshots to show how those JSDoc comments render into DocC. Key files: `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/fixtures/WebIDLDOMDocs.d.ts`, `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/fixtures/DOMLike.d.ts`, and the refreshed snapshot in `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/__snapshots__/ts2swift.test.js.snap`. Tests run: `npm test -- -u` (TS2Swift JavaScript).

* Removed the DOM-like fixture and refreshed snapshots to drop its output. Changes: deleted `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/fixtures/DOMLike.d.ts` and updated `Plugins/BridgeJS/Sources/TS2Swift/JavaScript/test/__snapshots__/ts2swift.test.js.snap`.

Tests: `npm test -- -u` (TS2Swift JavaScript).

Examples added/covered in this change:
- @JSFunction: enforce throws(JSException) (missing or wrong type) with note + fix-it ("Declare throws(JSException)").
- @JSFunction: instance members outside @jsclass emit a clear diagnostic.
- @JSGetter/@JSSetter: members (instance/static/class) outside @jsclass emit a clear diagnostic.
- @JSSetter: invalid setter names (e.g. updateFoo) emit a diagnostic and suggest a rename fix-it (e.g. setFoo).
- @JSSetter: missing value parameter emits a diagnostic and suggests adding a placeholder parameter.
- @jsclass: using @jsclass on non-struct declarations emits a diagnostic; for "class" also suggests "Change 'class' to 'struct'".

BridgeJS: Improve diagnostics and fix-its for macros

The new API allows managing JS closures converted from Swift closures
from Swift side. It allows us to get the underlying `JSObject` and
manage its lifetime manually from Swift.

```swift
@js func makeIntToInt() throws(JSException) -> JSTypedClosure<(Int) -> Int> {
    return JSTypedClosure { x in
        return x + 1
    }
}

@JSFunction func takeIntToInt(_ transform: JSTypedClosure<(Int) -> Int>) throws(JSException)

let closure = JSTypedClosure<(Int) -> Int> { x in
    return x * 2
}
defer { closure.release() }
try takeIntToInt(closure)
```

Likewise to `JSClosure`, API users are responsible for "manually" releasing the
closure when it's no longer needed by calling `release()`. After releasing,
the closure becomes unusable and calling it will throw a JS exception
(note that we will not segfault even if the closure is called after releasing).

```swift
let closure = JSTypedClosure<(Int) -> Int> { x in
    return x * 2
}
closure.release()
try closure(10)  // "JSException: Attempted to call a released JSTypedClosure created at <file>:<line>"
```

As a belt-and-suspenders measure, the underlying JS closure is also
registered with a `FinalizationRegistry` to ensure that the Swift closure box
is released when the JS closure is garbage collected, in case the API user
forgets to call `release()`. However, relying on this mechanism is **not recommended**
because the timing of garbage collection is non-deterministic and it's
not guaranteed that it will happen in a timely manner.

----

On the top of the new API, this commit also fixes memory leak issues of
closures exported to JS.

…erated bridge-js.js

…-fix

BridgeJS: Always provide swift_js_closure_unregister intrinsic in generated bridge-js.js

* [NFC] BridgeJS: Fix unused variable warning in BridgeJSCommandPlugin.swift

* [NFC] JavaScriptEventLoop: Fix warnings for undeclared SPI usage

Instead of crashing on errors in JS code generation for BridgeJSLink,
we should prefer propagating errors.

Centralize the `BridgeType` traversal logic and use it to collect
closure signatures in both `BridgeJSCore` and `BridgeJSLink`, removing
redundant code.

This is mostly NFC but added new closure signature collection paths for
`.array` and `.dictionary` element types and for enums with associated
values.

…ble (#606)

* [NFC] BridgeJS: Make JSGlueGen and IntrinsicJSFragment methods throwable

Instead of crashing on errors in JS code generation for BridgeJSLink,
we should prefer propagating errors.

* BridgeJS: Build fixes for profiling API

So that we can use it for Swift code generation

JSString.Guts previously held a raw JavaScriptObjectRef and released it
unconditionally on whatever thread ran deinit. In the multithreaded Wasm
runtime each thread has its own JSObjectSpace, so releasing a ref on the
wrong thread caused a TypeError crash (BugSnag: rc property of undefined).

JSObject already handles this correctly by capturing ownerTid at init time
and routing deinit through swjs_release_remote when destroyed off-thread.
This change makes Guts hold a JSObject instead of a raw ref, delegating the
correct cross-thread release behaviour to the existing JSObject.deinit path.

Adds a regression test testDeinitJSStringOnDifferentThread that reproduces
the crash deterministically: it forces JS ref allocation on the main thread
via asInternalJSRef(), then drops the last reference on a worker thread.

Fixes the crash seen in v292745-rc4 after upgrading to JavaScriptKit 0.50.2.

https://claude.ai/code/session_01Qhg5GLXZYNJtH63Gs1SwJH

…XtWUJ

BridgeJS: Fix closures with struct return

…ollision

BridgeJS: Fix name collision for same-named nested structs

BridgeJS: Add JSTypedArray convenience typealiases as recognized types

Add JSInt8Array, JSUint8Array, JSInt16Array, JSUint16Array, JSInt32Array,
JSUint32Array, JSFloat32Array, JSFloat64Array typealiases and pre-seed
them in SwiftToSkeleton so BridgeJS recognizes them in @js signatures.

Users can now write:
  @js func processData(_ data: JSUint8Array) -> JSUint8Array

Generated TypeScript uses native typed array names:
  processData(data: Uint8Array): Uint8Array

Bridging is reference-based (passes JSObject ID, no data copying).
Follows the existing JSPromise pre-seeding pattern.

…745)

#752)

Make Data typed-array constructor non-optional

Optional @js structs could not be used as parameters or return values of
imported (@JSFunction) signatures: the generator lowered Optional<Struct>
using the non-optional object-id ABI ([isSome, objectId] / a single Int32
return), for which no Optional lowering exists, so the generated thunk did
not compile.

Bridge optional @js structs through the stack ABI instead - an isSome
discriminator plus the struct fields - exactly like optional arrays and
dictionaries. Structs already conform to the stack-based bridging protocols,
so the existing _BridgedAsOptional/stack runtime extensions and the JS link's
stack handling already support this; only the import-side lowering/lifting in
the code generator needed to change.

Adds a jsRoundTripOptionalPoint runtime round-trip (some + none) and a
SwiftStructImports codegen snapshot.

BridgeJS: Support optional @js struct in imported function signatures

Case enums (enums without raw values or associated values) already bridged
across the export boundary as their Int32 tag, but the TypeScript import path
rejected them with "Enum types are not yet supported in TypeScript imports".
The JS glue already round-trips the tag in both directions, so enable case
enums as imported (@JSFunction) parameters and return values by lowering and
lifting that Int32 tag in the import context, matching the export side.

Adds a CaseEnumImports round-trip test and an EnumCaseImport codegen snapshot.

BridgeJS: Support case enums as imported function parameters and returns

A Wasm i64 parameter or return value is represented as a JavaScript BigInt.
The generated JS used a plain 0 as the placeholder for the absent case of an
optional i64 parameter (isSome ? v : 0) and for the error-path return of an
imported thunk, so calling such an export with null (or an imported i64
function throwing) raised "TypeError: Cannot convert 0 to a BigInt".

Emit 0n for i64 in both placeholders (jsZeroLiteral and the imported-thunk
return placeholder). This was latent because the optional Int64/UInt64
round-trip tests never exercised the none case; add those assertions.

…eral

#758)

BridgeJS: Support optional @jsclass as exported function parameters

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.

BridgeJS: Fix reject path of zero-parameter async throwing exports

* drop swift 6.1

* fix ci matrix

* Detach async JS bridge tasks

* Stabilize identity GC test

* Revert detached async bridge tasks

* Use Swift 6.2.4 in CI

* Use Swift 6.2.3 in CI

* Drop Swift 6.2 from CI

* Document minimum Swift version

* Add MSSV section to README

* Fix async closure test formatting

* Move tracing override to 24.04 matrix entry

* Use latest snapshot toolchain

* Use native build system for examples

* Use native build system in PackageToJS tests

* Fix build-examples CI hang

* Apply formatter output

* Match formatter whitespace

…paths (#764)

* BridgeJS: support associated-value enums in import and async paths

* Format Swift sources

* Match Swift 6.1 formatter output

…ention

BridgeJS: Support throws and async for closures