Import __wbindgen_bigint_from_i64 with Non-JS-compatible Func Sigurature (i64 as parameter)

[kylebarron]

Describe the Bug

After upgrading from 0.2.82 to 0.2.83 I appear to have an issue using the generated code from webpack (with the bundler target of wasm-pack).

ERROR in ./node_modules/parquet-wasm/bundler/arrow2_bg.wasm
Import "__wbindgen_bigint_from_i64" from "./arrow2_bg.js" with Non-JS-compatible Func Sigurature (i64 as parameter) can only be used for direct wasm to wasm dependencies
 @ ./node_modules/parquet-wasm/bundler/arrow2.js
 @ ./async_testing.js
 @ ./bootstrap.js

It looks like there were some bigint-related changes between 0.2.82 and 0.2.83 of wasm-bindgen. I had been returning i64 from some functions without issue before bumping to 0.2.83 so I think it's a change in wasm-bindgen

Steps to Reproduce

git clone https://github.com/kylebarron/parquet-wasm
cd parquet-wasm
git checkout e610ef632cb10d4618971a1fa8dcdb2005e673cf

# paths I have to set on MacOS for one of the dependencies to build correctly for wasm32
export PATH="/usr/local/opt/llvm/bin/:$PATH"
export CC=/usr/local/opt/llvm/bin/clang
export AR=/usr/local/opt/llvm/bin/llvm-ar

# Calls a build script that builds several wasm-pack binaries
yarn build

# Start webpack test project (originally from the wasm-pack template)
cd www
yarn install
yarn start

Specifically, the wasm-pack flags provided to the bundle that fails to load is

wasm-pack build --release \
  --out-name arrow2 --target bundler --no-default-features \
  --features arrow2 --features reader --features writer \
  --features all_compressions --features async

Using the previous version of wasm-bindgen generated a _bg.js file where the only grep of bigint was:

export function __wbindgen_bigint_new(arg0, arg1) {

Now there's a new function that triggers this webpack error:

export function __wbindgen_bigint_from_i64(arg0) {

Expected Behavior

Able to run application through webpack

Additional Context

wasm-pack 0.10.3
rustc 1.63.0 (4b91a6ea7 2022-08-08)

[kylebarron]

I assume this is a consequence of #3037?

[teague-lasser]

@alexcrichton This is a serious bug for us that breaks Big*Array uses in wasm-pack. We've had to pin back this release, I suggest this crate version be pulled until this is resolved.

[kylebarron]

In case they're not following all the issues here, I'll ping @Liamolucko and @RReverser for their thoughts on this

[RReverser]

Hm, not sure what's going on - seems like we pack's wasm parser doesn't support bigint integration still?

[RReverser]

I assume it's a combination with #3037 that's causing the issue, since that PR changed the ABI under an assumption that all engines support bigint<>i64 integration (which they do, but Webpack might be a special case).

[RReverser]

(oh sorry, just noticed you referenced the same issue, I thought it was #3049 or #3058 which is the culprit of the actual intrinsic at hand)

[RReverser]

Seems to be webpack/webpack#8531 which I guess never got resolved on the webpack side after being auto-closed? cc @xtuc

[kylebarron]

In my example above, I'm using Webpack 4, specifically 4.46.0. In my case it's just a toy example and maybe upgrading to Webpack 5 would fix this?

[RReverser]

Sorry, I'm on my phone so it's just a stream of thought as I'm trying to find relevant stuff.

webpack/webpack#8531 (comment) sounds like async Wasm integration should be fine, but the deprecated sync one still has a problem. I'm not sure which one is used by wasm-pack here?

[RReverser]

In my example above, I'm using Webpack 4, specifically 4.46.0. In my case it's just a toy example and maybe upgrading to Webpack 5 would fix this?

Oh yeah worth trying.

[RReverser]

Given that 4.46.0 is 2 years old (according to https://www.npmjs.com/package/webpack/v/4.46.0), that seems very likely that the feature was implemented after that. 2 years is a lot in Wasm land.

[kylebarron]

Given that 4.46.0 is 2 years old (according to https://www.npmjs.com/package/webpack/v/4.46.0), that seems very likely that the feature was implemented after that. 2 years is a lot in Wasm land.

I agree that it's a long time, so it may be that supporting Webpack 4 is no longer desired. Dropping support for Webpack 4 in a patch release seems like a big change and I just would've rather seen it as part of an 0.3 release. (Though given that the patch version is now in the 80s, maybe wasm-bindgen just doesn't use semver).

[RReverser]

Dropping support for Webpack 4 in a patch release seems like a big change and I just would've rather seen it as part of an 0.3 release.

Yeah I can agree with that, #3037 in general was probably a breaking change. I believe wasm-bindgen does follow semver and tries to avoid breaking issues until 0.3 at some point in the future.

[Liamolucko]

webpack/webpack#8531 (comment) sounds like async Wasm integration should be fine, but the deprecated sync one still has a problem. I'm not sure which one is used by wasm-pack here?

I think the sync version is just a compat mode for how wasm worked in webpack 4; so, webpack 4 has the same problem.

I think support could be added on Webpack's end by adding i64 to this list:

https://github.com/webpack/webpack/blob/9fcaa243573005d6fdece9a3f8d89a0e8b399613/lib/wasm-sync/WebAssemblyParser.js#L20

I haven't had a chance to actually test that, though.

It's the same in webpack 4:

https://github.com/webpack/webpack/blob/3956274f1eada621e105208dcab4608883cdfdb2/lib/wasm/WebAssemblyParser.js#L19