wasm-bindgen/wasm-bindgen - CodSpeed

wasm-bindgen

Blog Docs Changelog

Performance History

Latest Results

refactor: drop redundant struct keying fields from schema Now that exported_classes is keyed by qualified_name (#5154) and the wrap/unwrap aux imports route through that key, three fields carry no information that is not already derivable from (name, js_namespace): * AuxStruct.rust_name / Struct.rust_name (wire schema) — used to be the map key, replaced by qualified_name; no remaining cli-support reader after #5154/#5160, and no diagnostic surfacing in error messages or log output. * AuxStruct.qualified_name / AuxEnum.qualified_name — derivable on demand via wasm_bindgen_shared::qualified_name(js_namespace, name); storing it duplicates the (name, js_namespace) pair that AuxStruct already carries. * ExportedClass.qualified_name — duplicates the exported_classes map key. Three or_else fallback chains that exercised the pre-#5154 `rust_name` vs `qualified_name` disagreement collapse to direct uses of the key. The ancestors tuple shrinks from `(identifier, rust_name, qualified)` to `(identifier, qualified)` for the same reason: the rust_name slot was for the upcast-symbol parent half, which #5154 unified onto qualified_name on both sides via extends_js_class / extends_js_namespace. The release that ships #5154 is already a breaking schema bump (two new fields on Struct: extends_js_class / extends_js_namespace), so dropping rust_name in the same cycle costs nothing additional and avoids carrying a dead field forever. Schema hash re-approved.

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

7 days ago

refactor: drop redundant struct keying fields from schema Now that exported_classes is keyed by qualified_name (#5154) and the wrap/unwrap aux imports route through that key, three fields carry no information that is not already derivable from (name, js_namespace): * AuxStruct.rust_name / Struct.rust_name (wire schema) — used to be the map key, replaced by qualified_name; no remaining cli-support reader after #5154/#5160, and no diagnostic surfacing in error messages or log output. * AuxStruct.qualified_name / AuxEnum.qualified_name — derivable on demand via wasm_bindgen_shared::qualified_name(js_namespace, name); storing it duplicates the (name, js_namespace) pair that AuxStruct already carries. * ExportedClass.qualified_name — duplicates the exported_classes map key. Three or_else fallback chains that exercised the pre-#5154 `rust_name` vs `qualified_name` disagreement collapse to direct uses of the key. The ancestors tuple shrinks from `(identifier, rust_name, qualified)` to `(identifier, qualified)` for the same reason: the rust_name slot was for the upcast-symbol parent half, which #5154 unified onto qualified_name on both sides via extends_js_class / extends_js_namespace. The release that ships #5154 is already a breaking schema bump (two new fields on Struct: extends_js_class / extends_js_namespace), so dropping rust_name in the same cycle costs nothing additional and avoids carrying a dead field forever. Schema hash re-approved.

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

7 days ago

test: exercise the unwrap path for the minimal renamed standalone class `exported-class-rename-wrap` covered only the wrap import for the canonical rename-only (no namespace) case. Add a `Vec<RustRenamed>` consumer so the sibling `UnwrapExportedClass` import is emitted too: `Renamed.__unwrap`, keyed by the qualified JS identity `Renamed` rather than the Rust ident `RustRenamed`. As a standalone class with no subclass, its `__unwrap` is a plain `instanceof Renamed` check (contrast the pointer-identity check the inheriting classes in `exported-class-wrap-matrix` use).

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

8 days ago

refactor: remove dead qualified_to_rust_name map `Context::qualified_to_rust_name` was never populated (no `.insert` anywhere), so its single `.get` in `resolve_class_name` always returned `None` and that branch was dead. It was leftover scaffolding from the qualified-name keying refactor (#5154), which moved `exported_classes` to be keyed by `qualified_name`. Drop the field and the dead branch; `resolve_class_name` is now a direct passthrough (callers already hold the qualified-name key). Behavior is unchanged — all reference snapshots are byte-identical with no re-bless. Note: `AuxStruct.rust_name` is also unused in cli-support but is left as is — it already carries `#[allow(dead_code)]` upstream and is retained deliberately for diagnostics / backward compatibility, and `rust_name` remains part of the wire schema.

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

8 days ago

fix: key wrap/unwrap exported-class imports by qualified_name `WrapInExportedClass` / `UnwrapExportedClass` in cli-support's struct adapter were keyed by `rust_name`, but `exported_classes` is keyed by `qualified_name` (#5154). For a struct renamed via `js_name` and/or placed in a `js_namespace`, `require_class(rust_name)` missed and minted a fresh empty entry, emitting a duplicate phantom class whose `free()` referenced a nonexistent `__wbg_<rustname>_free` export. The phantom is what `__wrap` returned, so values crossing the boundary via `.into()` were the wrong class and trapped at GC. Key both imports by `qualified_name` to match the `exported_classes` keying. The sibling `RustFromI32` path already used `qualified_name`, so returning a struct by value was unaffected — only the JsValue conversion path duplicated. Re-blesses the two new fixtures to a single class each and the `js-namespace-export-same-name` fixture (which exercises both the wrap and unwrap paths) onto the qualified-name classes.

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

8 days ago

fix: key wrap/unwrap exported-class imports by qualified_name `WrapInExportedClass` / `UnwrapExportedClass` in cli-support's struct adapter were keyed by `rust_name`, but `exported_classes` is keyed by `qualified_name` (#5154). For a struct renamed via `js_name` (Rust ident != JS class name), `require_class(rust_name)` missed and minted a fresh empty entry, emitting a duplicate phantom class whose `free()` referenced a nonexistent `__wbg_<rustname>_free` export. The phantom is what `__wrap` returned, so values crossing the boundary via `.into()` were the wrong class and trapped at GC. Key both imports by `qualified_name` to match the `exported_classes` keying. The sibling `RustFromI32` path already used `qualified_name`, so returning a struct by value was unaffected — only the JsValue conversion path duplicated. Re-blesses the new `exported-class-rename-wrap` fixture to a single class and the `js-namespace-export-same-name` fixture (which exercises both the wrap and unwrap paths) onto the qualified-name classes.

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

8 days ago

test: reference fixture for renamed exported struct converted to JsValue Captures current codegen for a struct renamed via `js_name` (Rust ident `RustRenamed` != JS class `Renamed`, no `js_namespace`) that is converted to `JsValue` via `.into()`. The blessed snapshot shows the regression introduced by the qualified-name keying refactor in #5154: the `From<RustRenamed> for JsValue` wrap import (`WrapInExportedClass`) is keyed by the Rust ident, so cli-support mints a duplicate phantom `class RustRenamed` alongside the real `class Renamed`. The phantom's `free()` references a nonexistent `__wbg_rustrenamed_free` export, and `makeRenamed` returns `RustRenamed.__wrap(...)`, so instances are the wrong class and trap at GC. Fix follows in the next commit (re-blesses this fixture to a single class).

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

8 days ago

fix: Handle `Br` and `BrIf` instructions in the descriptor interpreter (#5158)

main

8 days ago

Latest Branches

-11%

fix: key WrapInExportedClass/UnwrapExportedClass by qualified_name (renamed-struct .into() duplicate class)#5160

7 days ago

5e0d7be

ZhaoXiangXML:fix/wrap-exported-class-qualified-name

-3%

build(deps): update shlex requirement from 1 to 2#5159

10 days ago

dc28cf2

dependabot/cargo/shlex-2

-27%

fix: Handle `Br` and `BrIf` instructions in the descriptor interpreter#5158

11 days ago

6a10b14

connyay:cjh-br-5157

© 2026 CodSpeed Technology

Home Terms Privacy Docs