swiftwasm / swiftwasm/JavaScriptKit

BridgeJS: Remove JSException storage boxing once swiftlang/swift#89715 lands

Abierto
#767 0 comentarios 0 reacciones 1 asignado Ver en GitHub

@krodak ya está trabajando en esto.

Desde el 11/6/2026.

Lenguaje dominante
Swift
Estrellas
986
Forks
76
Merge medio
21 h 11 min
PR fusionados (30 d)
4

Descripción

Tracks removal of the JSException storage boxing introduced in #766.

Context

swiftlang/swift#89320 miscompiles Wasm calls to captureless async throws(JSException) closure values when the typed error exceeds the direct error convention: the thrown error is corrupted across the async unwind, so the rejected Promise receives garbage. JSException (~36 bytes) always took the affected indirect-error path.

#766 works around this at the library level by boxing JSException's stored properties (thrownValue, description, stack) into a private final class, shrinking the struct to a single stored reference so it travels in the direct error convention and the broken path is never taken. The public API is unchanged; the cost is one heap allocation per thrown exception. The original exploration is in https://github.com/PassiveLogic/JavaScriptKit/pull/13.

The codegen-level counterpart for zero-parameter async throwing exports is tracked separately in #761.

What to do once the compiler fix ships

The proper fix is swiftlang/swift#89715 (IRGen: fix async typed throws miscompiles on Wasm). Once it is available in the oldest Swift toolchain JavaScriptKit supports:

  • Move thrownValue, description, and stack back to stored properties on JSException and delete the Storage class. This is a library-internal layout change only, not a breaking API change.
  • Keep the async closure reject end-to-end tests as the regression guard that the reject path still works without the boxing.

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.