[pull] main from swiftwasm:main by pull[bot] · Pull Request #7 · majacQ/JavaScriptKit
…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.
…-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
[NFC] BridgeJS: Move CodeFragmentPrinter to BridgeJSCore
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.
#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.
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
BridgeJS: Support throws and async for closures
…tions BridgeJS: Normalize wasm pointer offsets in JS
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters