Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add i64 to the set of JS-compatible wasm types in syncWebAssembly mode #16339

Merged
merged 2 commits into from Nov 9, 2022

Conversation

Liamolucko
Copy link
Contributor

For quite a while now, it's been possible for WebAssembly i64s to be converted to/from JS bigints (as function parameters, results, etc.). However, syncWebAssembly mode currently rejects any modules that attempt to do so, because i64 isn't in it's list of JS-compatible types. This fixes that by adding i64 to that list.

Fixes #8531, although that was already closed from inactivity.

(Note: this fix is mainly meant for being backported to webpack 4, since syncWebAssembly is deprecated anyway, but I've implemented it against webpack 5 first.)

This caused rustwasm/wasm-bindgen#3095 when wasm-bindgen switched to directly pass 64-bit integers as i64s rather than as a pair of i32s; that issue is mostly about webpack 4, though, so this'll need to be backported before that's fixed.

There was an existing test that used i64 as an example of a non-JS-compatible type; I replaced that with v128.

… mode

For quite a while now, it's been possible for WebAssembly `i64`s to be converted to/from JS bigints (as function parameters, results, etc.). However, `syncWebAssembly` mode currently rejects any modules that attempt to do so, because `i64` isn't in it's list of JS-compatible types. This fixes that by adding `i64` to that list.

There was an existing test that used `i64` as an example of a non-JS-compatible type; I replaced that with `v128`.
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 6, 2022

CLA Signed

The committers listed above are authorized under a signed CLA.

  • ✅ login: Liamolucko / name: Liam Murphy (a74f64e)

@webpack-bot
Copy link
Contributor

For maintainers only:

  • This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
  • This needs to be backported to webpack 4 (issue will be created when merged)

Copy link
Member

@alexander-akait alexander-akait left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you

@Liamolucko
Copy link
Contributor Author

The CI failure looks to be unrelated to my changes.

@sokra sokra merged commit f7f36ad into webpack:main Nov 9, 2022
@sokra
Copy link
Member

sokra commented Nov 9, 2022

Thanks

@kylebarron
Copy link

(Note: this fix is mainly meant for being backported to webpack 4, since syncWebAssembly is deprecated anyway, but I've implemented it against webpack 5 first.)

Given that there hasn't been a v4 release in almost two years, is it safe to assume this won't be backported?

jcbhl added a commit to jcbhl/puzzle-solver that referenced this pull request Jul 27, 2023
Running into challenges. The Rust part compiles, but when building with
Webpack, I get this error:
```
ERROR in ./pkg/index_bg.wasm
Import "__wbindgen_bigint_from_u64" from "./index_bg.js" with
Non-JS-compatible Func Sigurature (i64 as parameter) can only be used
for direct wasm to wasm dependencies
 @ ./pkg/index.js
 @ ./js/index.js
ℹ 「wdm」: Failed to compile.
```

This issue (rustwasm/wasm-bindgen#3095) talks
about the same problem. The fix
(webpack/webpack#16339) was merged but not
backported into Webpack 4, so I'm going to have to try and upgrade to
fix.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[WASM] - experimental BigInt/I64 support
5 participants