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 |
|
I went ahead and implemented the proposal from #4211 (comment) in #4235: reference type proposal transformations aren't enabled by default for the bundler target. Please let me know if this addresses at least the majority of use-cases out there. |
|
Works for our code. Thanks! |
|
I apologize for the premature false positive. Our stack was giving 0 exit status and ending with a lot of lines of output that looked right, even though there was a panic: After that follows 32 lines of webpack output showing webpack doing things as if everything was running fine, terminating with: IOW, webpack didn't notice the error and stop what it was doing and exit with a non-0 status. I was in the middle of lunch but was (too) eager to let you know that it worked that I posted once I saw what I thought was a happy build. Here's the output with a full backtrace: |
|
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 |
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: