Can't build front-end with rust 1.82.0

[ctm]

Fix the regression that causes yarn dev to fail.

I was able to build earlier today. I've since upgraded the sass npm package and done a cargo update, but when I back off to origin/master the build still fails. My guess is there's a non-Rust artifact that got borked somehow.

[ctm]

This appears to be due to rust 1.82.0. I can now build after having done:

rustup install 1.81.0
rustup default 1.81.0

I'll now poke around and see if anyone else has mentioned this on the web. My guess is it's already been mentioned in a chat room somewhere.

[ctm]

I haven't yet found a report of anyone else having this problem, but I've tried changing the default back to 1.82.0 and the error reappears. FTR, here it is:

ERROR in ./pkg/index_bg.wasm
Module parse failed: Internal failure: parseVec could not cast the value
You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
Error: Internal failure: parseVec could not cast the value
    at parseVec (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/@webassemblyjs/wasm-parser/lib/decoder.js:343:15)
    at parseTypeSection (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/@webassemblyjs/wasm-parser/lib/decoder.js:375:22)
    at parseSection (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/@webassemblyjs/wasm-parser/lib/decoder.js:1379:23)
    at Object.decode (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/@webassemblyjs/wasm-parser/lib/decoder.js:1740:25)
    at decode (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/@webassemblyjs/wasm-parser/lib/index.js:253:21)
    at WebAssemblyParser.parse (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/webpack/lib/wasm-sync/WebAssemblyParser.js:92:19)
    at /Users/ctm/poker/rust/poker/front-ends/web/node_modules/webpack/lib/NormalModule.js:1303:19
    at processResult (/Users/ctm/poker/rust/poker/front-ends/web/node_modules/webpack/lib/NormalModule.js:937:11)
    at /Users/ctm/poker/rust/poker/front-ends/web/node_modules/webpack/lib/NormalModule.js:1030:5
    at /Users/ctm/poker/rust/poker/front-ends/web/node_modules/loader-runner/lib/LoaderRunner.js:407:3
 @ ./pkg/index.js 1:0-40 4:15-19 5:0-21
 @ ./bootstrap.js 96:0-15

webpack 5.95.0 compiled with 1 error in 63668 ms

[ctm]

Looks like this is a known issue. Ugh.

[ctm]

So, if I want to use rust 1.82, I'll need to figure out how to disable the reference-types feature for wasm32-unknown-unknown, I think. I know how to disable features for individual crates in Cargo.toml, but I don't yet know how to disable reference-types for the compiler itself. Perhaps I'm supposed to set target-cpu to mvp as per the Enabled WebAssembly Features documentation.

FWIW, the extended rust 1.82 documentation mentions that reference-types is enabled by default in their Compatibility Notes. Looks like I need to pass -Zbuild-std in somewhere, but I don't yet know where. FWIW, this did not work:

[master]% git diff
diff --git a/front-ends/web/.cargo/config.toml b/front-ends/web/.cargo/config.toml
index 84671750..9e6935b0 100644
--- a/front-ends/web/.cargo/config.toml
+++ b/front-ends/web/.cargo/config.toml
@@ -1,2 +1,5 @@
+[unstable]
+build-std = ["core", "alloc"]
+
 [build]
-rustflags = ["--cfg=web_sys_unstable_apis"]
+rustflags = ["--cfg=web_sys_unstable_apis","-C","target-cpu=mvp"]

[ctm]

FWIW, using rustflags = ["--cfg=web_sys_unstable_apis","-Ctarget-cpu=mvp"] doesn't work, either.

[ctm]

The Hello World! wasm-bindgen example works with rust 1.81.0 and fails with 1.82.0, and it uses webpack. This gives me a place to report the bug and maybe someone looking at it can find the magic incantation to make it work again.

[ctm]

Reported

[ctm]

I did some more reading and futzing around and now realize that [unstable] will not work with a 1.82.0, because 1.82.0 is stable. So, I tried rustup default nightly and then build-std kicked in, although all the permutations I tried resulted in a duplicate lang item failures, e.g.:

   Compiling wasm-sockets v1.0.1 (https://github.com/ctm/wasm-sockets?branch=error-7#9ad7279c)
error[E0152]: duplicate lang item in crate `core`: `sized`
  |
  = note: the lang item is first defined in crate `core` (which `wasm_sockets` depends on)
  = note: first definition in `core` loaded from /Users/ctm/poker/rust/poker/target/wasm32-unknown-unknown/debug/deps/libcore-0a1b609703697ba4.rlib, /Users/ctm/poker/rust/poker/target/wasm32-unknown-unknown/debug/deps/libcore-0a1b609703697ba4.rmeta
  = note: second definition in `core` loaded from /Users/ctm/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-192e883b194683b6.rlib

For more information about this error, try `rustc --explain E0152`.
error: could not compile `wasm-sockets` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Error: Compiling your crate to WebAssembly failed

and

error[E0152]: duplicate lang item in crate `core` (which `alloc` depends on): `sized`
  |
  = note: the lang item is first defined in crate `core` (which `futures_sink` depends on)
  = note: first definition in `core` loaded from /Users/ctm/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-192e883b194683b6.rlib
  = note: second definition in `core` loaded from /Users/ctm/poker/rust/poker/target/wasm32-unknown-unknown/debug/deps/libcore-0a1b609703697ba4.rmeta

For more information about this error, try `rustc --explain E0152`.
error[E0152]: duplicate lang item in crate `core` (which `alloc` depends on): `sized`
  |
  = note: the lang item is first defined in crate `core` (which `futures_core` depends on)
  = note: first definition in `core` loaded from /Users/ctm/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/wasm32-unknown-unknown/lib/libcore-192e883b194683b6.rlib
  = note: second definition in `core` loaded from /Users/ctm/poker/rust/poker/target/wasm32-unknown-unknown/debug/deps/libcore-0a1b609703697ba4.rmeta

error: could not compile `futures-sink` (lib) due to 1 previous error

To me, this looks like I'm getting somewhere, but I need another flag somewhere that says not only do we want to build our own copy of core, but we don't want to use the pre-compiled copy of core. If so, it may be that there's something else that I can do or it may be that because webpack's wasm-pack-plugin replicates some of cargo's functionality, that this particular aspect (don't include the pre-compiled versions when using -Zbuild-std) isn't implemented.

I have not yet looked at the source of wasm-pack-plugin, but doing so may provide useful information.

[ctm]

Turns out wasm-pack-plugin is just a wrapper around wasm-pack, which contains a file src/manifest/mod.rs whose introductory comment is Reading and writing Cargo.toml and package.json manifests. That strongly suggests to me that cargo itself is not invoked and that wasm-pack pays attention to some (much?, most?) of what's in Cargo.toml, but build-std doesn't show up in any of the source:

[master]% rg -il build-std
[master]% 

That suggests to me that the build-std key isn't used by wasm-pack, but that doesn't mean that there's not some additional way to tell it to ignore the pre-compiled crates that are being compiled explicitly via the build-std key in the unstable block. It does tell me, however, that it makes more sense for me to find the right person to ask rather than to dig even further into the code.

[ctm]

Aha. The cargo -Z flag is specifically for unstable features. Perhaps I knew that at one time, but since in general, I eschew unstable features and since the unstable features that I have played with in the past are compiler unstable features, I managed to overlook the nature of -Z, especially since it was recommended in the Compatibility Notes section of the detailed 1.82.0 release notes.

So, the upshot is that the release notes for a stable release says that if you want to continue using tools that you've been using in the past, you must use an unstable feature, without explicitly mentioning that this means you can't—by definition—use the version being documented in the release notes. That was counter-intuitive.

This strongly suggests that mb2 won't be able to use a stable rust release until they either make it so that reference-types is not enabled by default or provide a stable way (that works through the wasm-pack stack) to disable that default.