left: `2`, right: `1`, crates/cli-support/src/js/mod.rs:2745:17

[renatoathaydes]

Describe the Bug

I have made a few innocent looking changes to my code that was previously working fine. Now it wasmpack fails when I run this command:

wasm-pack build --target web --no-typescript

... 

[INFO]: ⬇️  Installing wasm-bindgen...
thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', crates/cli-support/src/js/mod.rs:2745:17
stack backtrace:
   0:        0x1090da304 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hcfc48256a5ab8835
   1:        0x1090f8a00 - core::fmt::write::haf3903118f694c48
   2:        0x1090d7496 - std::io::Write::write_fmt::h7385463ac87804ed
   3:        0x1090dbd7f - std::panicking::default_hook::{{closure}}::h91bd4c58cf71392b
   4:        0x1090dba4d - std::panicking::default_hook::h7bd29c87df967048
   5:        0x1090dc34b - std::panicking::rust_panic_with_hook::hae2b05f08a320721
   6:        0x1090dbecb - std::panicking::begin_panic_handler::{{closure}}::h72d68d3a77e0b718
   7:        0x1090da778 - std::sys_common::backtrace::__rust_end_short_backtrace::h7c5e286792f94edb
   8:        0x1090dbe8a - _rust_begin_unwind
   9:        0x10912b15b - std::panicking::begin_panic_fmt::h6826a3ebe3a95a51
  10:        0x108e18d8a - wasm_bindgen_cli_support::js::Context::invoke_import::h1346e568022b27de
  11:        0x108e6c18c - wasm_bindgen_cli_support::js::binding::instruction::h3ab0e8c1f837816a
  12:        0x108e628c3 - wasm_bindgen_cli_support::js::binding::Builder::process::ha097d07b4a8b00f8
  13:        0x108e10ebf - wasm_bindgen_cli_support::js::Context::generate::hebc298268fc9acc3
  14:        0x108e27654 - wasm_bindgen_cli_support::Bindgen::generate_output::hebe5328caf510c3f
  15:        0x108de8592 - wasm_bindgen_cli_support::Bindgen::generate::h6e6e49d758260885
  16:        0x108debb21 - wasm_bindgen::main::hc3ab957f18625d20
  17:        0x108de9aba - std::sys_common::backtrace::__rust_begin_short_backtrace::h3315c83da1796513
  18:        0x108de9afc - std::rt::lang_start::{{closure}}::h0a054103414d967f
  19:        0x1090dc7a4 - std::rt::lang_start_internal::hd38bb63f9540b327
  20:        0x108dec059 - _main
Error: Running the wasm-bindgen CLI
Caused by: failed to execute `wasm-bindgen`: exited with exit code: 101

Steps to Reproduce

I am sorry but I can't find simple steps to reproduce. I realize this makes it very hard to find out what's wrong, but I am creating this ticket to at least get some assistance on what can be the root cause of the error, given that the error message does not provide any hints.

Expected Behavior

The code compiles with Rustc and wasmpack should either work or give an error message explaining what's wrong.

Actual Behavior

Error message does not make sense:

'assertion failed: `(left == right)`
  left: `2`,
 right: `1`'

Additional Context

Versions (latest stable):

wasm-pack 0.9.1
cargo 1.49.0 (d00d64df9 2020-12-05)
rustc 1.49.0 (e1884a8e3 2020-12-29)

[renatoathaydes]

It was very hard to find out which line of code was causing the issue, but now I have narrowed it down to a usage of async fn which returned a Result<Response, JsValue>, breaking the rule at https://rustwasm.github.io/wasm-bindgen/reference/js-promises-and-rust-futures.html#return-values-of-async-fn that says async fn cannot return just any type.

I fixed that, but now it's still failing to compile.

Here's the signature of my function now:

pub async fn send_dpop_request(data: &HttpRequestData, key: &Key) -> Result<JsValue, JsValue>

Which I use elsewhere like this:

async fn handle_http_req_message(trace_id: JsValue, data: JsValue) -> Result<JsValue, JsValue> {
   ...
        let resp_js = send_dpop_request(&request_data, &key).await?;
        let response: Result<Response, JsValue> = resp_js.dyn_into();
   ...

This also fails to compile.

If I replace the last line with this, it compiles:

let response: Result<Response, JsValue> = unimplemented!();

It seems that dyn_into() cast is what's failing.

[alexcrichton]

Thanks for the report! Unfortunately I probably can't help much without a reproduction. This definitely looks like a bug in wasm-bindgen, but I'm not sure where it is or what would trigger it :(

[renatoathaydes]

Yeah, sorry about that. But I can tell you for sure that it seems related to moving the Response object from async fn then trying to do dyn_into() from a JsValue. Should be easy to reproduce, but I already spent 2 days on this bug so wont' be able to help you right now.

[renatoathaydes]

By the way: I didn't overcome the issue, I just wrote this part of the code in Js :/

[prestwich]

Probably unrelated but, I got a very similar error (note the different line number), when I had accidentally marked a method #[wasm_bindgen(getter)] with no &self parameter

e.g.

#[wasm_bindgen]
impl Type {
   #[wasm_bindgen(getter)]
   pub fn func() -> usize { ... }
}

produces

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `2`,
 right: `1`', crates/cli-support/src/js/binding.rs:166:9

[dylanowen]

I also ran into a similar issue recently with this rust input:

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(extends = js_sys::Object)]
    pub type Panels;

    #[wasm_bindgen(method, getter)]
    pub fn create(this: &Panels, title: &str, icon_path: &str, page_path: &str);
}

Obviously create can't be a getter with the additional arguments.

thread 'main' panicked at 'assertion failed: `(left == right)`
  left: `4`,
 right: `1`', crates/cli-support/src/js/mod.rs:3033:17
stack backtrace:
   0: rust_begin_unwind
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/panicking.rs:65:14
   2: core::panicking::assert_failed_inner
             at /rustc/90743e7298aca107ddaa0c202a4d3604e29bfeb6/library/core/src/panicking.rs:246:17
   3: core::panicking::assert_failed
   4: wasm_bindgen_cli_support::js::Context::invoke_import
   5: wasm_bindgen_cli_support::js::binding::instruction
   6: wasm_bindgen_cli_support::js::binding::Builder::process
   7: wasm_bindgen_cli_support::js::Context::generate
   8: wasm_bindgen_cli_support::Bindgen::generate_output
   9: wasm_bindgen_cli_support::Bindgen::generate
  10: wasm_bindgen::main

I seem to recall that bugs like this used to be caught in the rust compilation phase and never making it to the wasm-bindgen phase.

Unfortunately if bugs like this are making it to the wasm-bindgen phase the assertions make it quite difficult to figure out the exact issue. For my case I added a bail! statement instead of an assert and it helped me figure out my issue. I wonder if it would be worth it to move our assertions to bail! so we at least get the context of where the failure is coming from.

My change: https://github.com/dylanowen/wasm-bindgen/commit/c09af342108a509e7b29a0886ec70bcf0ef3e80e