Rust v1.82 enables reference type transformations by default #4211
Comments
|
I second this, cannot get this working on latest versions Rust: 1.82 Trying to add a |
|
Upon further reading and experimenting, I suspect that for now it will simply impossible to use 1.82.0 with anything that uses |
|
Similarly, Rust 1.82 and Node 18 don't play well together when running |
|
So there's multiple things at play here. LLVM activated the The problem is that wasm-bindgen/crates/cli-support/src/lib.rs Lines 326 to 330 in 76776ef Usually you are meant to use the This by itself isn't really a problem, but @daxpedda I propose that |
This also pin the Rust toolchain to 1.81.0. We can look into removing this pin once the issue between the wasm bindings between 1.82 and Node 18. ### References - rustwasm/wasm-bindgen#4211 - cloudflare/workers-rs#654
|
I literally created this exact issue last 2 weeks and it was quickly dismissed. I am glad it's finally being worked on as this is a major issue. |
|
Running into the same issue here: Using react 18 with CRA-generated config, applying the following overrides to get wasm to work: if (!config.resolve.extensions) {
config.resolve.extensions = [];
}
if (!config.resolve.extensions.includes(".wasm")) {
config.resolve.extensions.push(".wasm");
}
const wasmExtensionRegExp = /\.wasm$/;
if (!config.module.rules) {
config.module.rules = [];
}
// Ensure that file-loader ignores WASM files.
// Sourced from https://prestonrichey.com/blog/react-rust-wasm/
config.module.rules.forEach((rule) => {
(rule.oneOf || []).forEach((oneOf) => {
if (oneOf.loader && oneOf.loader.indexOf("file-loader") >= 0) {
// Make file-loader ignore WASM files
oneOf.exclude.push(wasmExtensionRegExp);
}
});
});
// Use wasm-loader for WASM files
config.module.rules.push({
test: wasmExtensionRegExp,
// I'm going to level with you: I copied this in from the example, but I
// have no idea why it's necessary. If it's not here, it breaks, though.
include: path.resolve(__dirname, "src"),
use: [{ loader: require.resolve("wasm-loader"), options: {} }],
});Definitely seems limited to webpack for the bundler target specifically. We use the same package compiled for the nodejs target in Node without issues, as well as in svelte via vite. |
It seems that reference types from WASM are not supported by `wasm-parser` crate (rustwasm/wasm-bindgen#4211). It makes us pin to the recent nightly toolchain version that works, and contribution experience gets quite convoluted. Hopefully there is an option to disable `reference-types` with a flag: `-C target-cpu=mvp` for `wasm32-unknown-unknown` target. Resolves #374 Single source of rust toolchain from `rust-toolchain.toml` added for ci pipelines (actions-rust-lang/setup-rust-toolchain@v1 gh action used for that). Resolves #294
My first gut feeling is to continue as-is. Unfortunately, I'm a really clueless about Inherently, this is a problem that should be solved by Rustc and not by In that light, I will go ahead and pin this issue so we can get as much input as possible before settling on a solution! |
daxpedda
changed the title
|
My PR as per my testing fully unblocks the webpack ecosystem. It would only be a short term bugfix to unblock people who have been affected by it. I'm slowing working on PR on supporting reference types fully in webassemblyjs / webpack, but it probably is still taking a while (also depending on how responsive the maintainer is). So I would recommend going with my PR until webpack is fixed, which hopefully shouldn't take too long (but probably in the range of multiple months). |
|
While I wouldn't mind holding off until then, I would like to know how this is going to play out in the future. What do we do when LLVM enables other proposals by default which break ls it possible to move |
|
Just speaking for us as an example, we have a large, legacy application react using webpack. We would love to be able to move off of it, and we are in the process of doing so, but it is going to take some time. It would be great to not have to pin our Rust compiler to an old version until that happens, so a temporary fix would be helpful, whether that be here, in a webpack plugin, or wherever. |
This seem to work for now |
|
Will give that a shot, thanks for the link!
…On Tue, Oct 29, 2024 at 20:49 Kofi Otuo ***@***.***> wrote:
Just speaking for us as an example, we have a large, legacy application
react using webpack. We would love to be able to move off of it, and we are
in the process of doing so, but it is going to take some time. It would be
great to not have to pin our Rust compiler to an old version until that
happens, so a temporary fix would be helpful, whether that be here, in a
webpack plugin, or wherever.
This seem to work for now
webpack/webpack#15566 (comment)
<webpack/webpack#15566 (comment)>
—
Reply to this email directly, view it on GitHub
<#4211 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTQRYLV7CHFR6UJPUDG3XTZ6AUK5AVCNFSM6AAAAABQGQXODCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBVGU4DKMJUGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
FYI the Added the following in the package's [build]
strip = true
[profile.dev]
strip = true
[profile.release]
lto = true
opt-level = 'z'
strip = truebut still get the following when trying to import the WASM file in the built application: |
This sample repository works |
|
Yeah, I believe this could be due to some settings in create-react-app? Our current override is to include wasm files and load them with the |
|
That is a different error entirely. |
|
Thanks! Aha. Yes. I was inadvertently running an old All I had done to get the wasm-bindgen crate was to have added to my top-level So now that I've also done a |
|
So these are all the use-cases that have surfaced so far:
|
|
Hi, everyone. It seems that the wasm files packaged with wasm-pack still can’t be processed by webpack. I have confirmed that both webpack and webassemblyjs are updated to the latest versions, yet I’m still encountering the following error: Currently, it only works correctly if I set strip = true in the Cargo.toml file. I’d like to know if this issue has not yet been fully resolved, or if using strip = true is the final solution. |
|
The next release is going to not apply reference type transformation when using the bundler output, which should fix this. However, I'm not sure what that |
|
@daxpedda Thanks for the response. Alright, I’ll use strip = true as a temporary solution and wait for the next release. |
Problem: due to an intersection of changes in LLVM and wasm-bindgen described here[1], compiling with rustc1 1.82.0 breaks the WebPack webassembly integration. It looks like wasm-bindgen plan to push a fix for this (despite it not really being their responsibility) but that's not in yet. Solution: pin the compiler to 1.81 until the wasm-bindgen fix is int. [1]: rustwasm/wasm-bindgen#4211
Problem: due to an intersection of changes in LLVM and wasm-bindgen described here[1], compiling with rustc1 1.82.0 breaks the WebPack webassembly integration. It looks like wasm-bindgen plan to push a fix for this (despite it not really being their responsibility) but that's not in yet. Solution: pin the compiler to 1.81 until the wasm-bindgen fix is int. [1]: rustwasm/wasm-bindgen#4211
Problem: due to an intersection of changes in LLVM and wasm-bindgen described here[1], compiling with rustc1 1.82.0 breaks the WebPack webassembly integration. It looks like wasm-bindgen plan to push a fix for this (despite it not really being their responsibility) but that's not in yet. Solution: pin the compiler to 1.81 until the wasm-bindgen fix is int. [1]: rustwasm/wasm-bindgen#4211
Problem: due to an intersection of changes in LLVM and wasm-bindgen described here[1], compiling with rustc1 1.82.0 breaks the WebPack webassembly integration. It looks like wasm-bindgen plan to push a fix for this (despite it not really being their responsibility) but that's not in yet. Solution: pin the compiler to 1.81 until the wasm-bindgen fix is int. [1]: rustwasm/wasm-bindgen#4211
Problem: due to an intersection of changes in LLVM and wasm-bindgen described here[1], compiling with rustc1 1.82.0 breaks the WebPack webassembly integration. It looks like wasm-bindgen plan to push a fix for this (despite it not really being their responsibility) but that's not in yet. Solution: pin the compiler to 1.81 until the wasm-bindgen fix is int. [1]: rustwasm/wasm-bindgen#4211
|
With #4253 I consider this issue resolved. To summarize: this is not a In practice, if you are relying on a toolchain that does not support the reference type proposal, please update it!
To answer my own question: the reference type proposal changes the way tables are encoded. So by removing the table containing debug information, it triggers the output by LLVM (or |
The ubuntu-latest image uses Node v18, which isn't compatible with wasm-bindgen-test when building with Rust 1.82+ due to the use of LLVM's `reference-types` feature, see: rustwasm/wasm-bindgen#4211 ubuntu-24.04 includes Node v20 which doesn't have the same problem, allowing the wasm tests to move back to stable.
The ubuntu-latest image uses Node v18, which isn't compatible with wasm-bindgen-test when building with Rust 1.82+ due to the use of LLVM's `reference-types` feature, see: rustwasm/wasm-bindgen#4211 ubuntu-24.04 includes Node v20 which doesn't have the same problem, allowing the wasm tests to move back to stable.
Both of these are far from ideal though... :/ |
|
At least if |
Describe the Bug
The Hello World! example fails to run or even compile with Rust 1.82.0, presumably due to reference types. That example uses webpack with a configuration that will invoke @webassemblyjs/wasm-parser which doesn't support reference types. This other bug report has a backtrace that is similar to what happens now.
Steps to Reproduce (when using Rust 1.82.0)
cd examples/hello_worldyarn install, I'm sure npm has something similar, possiblynpm install)npm run buildoryarn build)Everything you need is in this repository other than installing the npm modules.
Expected Behavior
Actual Behavior
Additional Context
I believe this can be fixed by disabling the
reference-typesfeature forwasm32-unknown-unknown, however even after reading theEnabled WebAssembly Featuressection of the rustc book (and trying various things), I have not been successful at disabling that feature.The text was updated successfully, but these errors were encountered: