bytecodealliance/cargo-wasi

cargo wasi build with wasm-bindgen dep in cargo.toml but not used results in build error

Closed this issue · 3 comments

# Cargo.toml

[package]
name = "hello-multi-value"
version = "0.1.0"
authors = ["Nick Fitzgerald <fitzgen@gmail.com>"]
edition = "2018"



# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.54"
// src/lib.rs

#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        assert_eq!(2 + 2, 4);
    }
}
$ cargo wasi build
   Compiling hello-multi-value v0.1.0 (/home/fitzgen/scratch/hello-multi-value)
    Finished dev [unoptimized + debuginfo] target(s) in 0.16s
 Downloading precompiled wasm-bindgen v0.2.54
error: failed to find heap alloc

error: failed to process wasm at `/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/hello_multi_value.rustc.wasm`

Caused by:
    failed to execute "/home/fitzgen/.cache/cargo-wasi/0.1.16/wasm-bindgen/0.2.54/wasm-bindgen" "/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/hello_multi_value.rustc.wasm" "--keep-debug" "--out-dir" "/home/fitzgen/scratch/hello-multi-value/target/wasm32-wasi/debug/.tmpMS6NTH" "--out-name" "foo"
        status: exit code: 1

I think the root cause is in wasm-bindgen but it is more clear that this is a bug and not expected behavior in the context of cargo wasi.

This appears to be originating in the anyref xform, and we probably just need to gracefully handle when there aren't any anyrefs better.

Hm this is a bit worrisome yeah. I think though the right fix here is to get wasm-bindgen working over a file where it wasn't linked, that seem ok to you?

The output here is also somewhat unfortunate, but wasm-bindgen should only generate an error pretty rarely (in theory) so I was hoping it wasn't too important to improve the error output here.

I think though the right fix here is to get wasm-bindgen working over a file where it wasn't linked, that seem ok to you?

Yeah totally.

I mostly filed it here because this is how I got the bug, and I could see "don't run wasm-bindgen on a wasm file that doesn't use wasm-bindgen" being a reasonable position without the larger context that this issue attempted to provide.

Heh no worries! Just wanted to make sure we're on the same page :)

Pushed a fix up at rustwasm/wasm-bindgen#1861