Add exporting Rust functions as variadic JS functions

[joaofreires]

This is an attempt to solve #694.

I kept the variadic bindgen attribute and assumed the last argument will be received as a JS Array object with the variadic values. Added a variadic flag inside the Functions structures, and changed the export signature of functions flagged as variadic, then only the JS signature changed.

I found a limitation in this implementation around the argument typing export. If we export a variadic function with a type different from JsValue, we can generate the TS exports with wrong types.

For example:

#[wasm_bindgen(variadic)]
pub fn example(arr: &Array) {}

Will generate:

export function example(...arr: Array<any>): void;

The workaround I found is create a new type and export the typescript_type (I tested extending the Array structure and it worked as "expected").

Suggestions are welcome.

TODO:

• create more unit tests covering more variadic function use posibilities
• add the variadic "dots" in the JSDoc generation code.

[alexcrichton]

Seems reasonable to me! Could a typescript test be added to ensure that it shows up in the *.d.ts file correctly too?

[alexcrichton]

I think this can be removed now?

[ranile]

👍

We shouldn't have dead code in there without a reason

[joaofreires]

Yes, removed!

[ranile]

Why have dead code in there? Can you please add a comment explaining why this is commented out?

[joaofreires]

Removed, no longer needed.

[ranile]

👍

We shouldn't have dead code in there without a reason

[joaofreires]

I created tests for simple variadic functions inside crates/typescript-tests/src/simple_fn.[rs | ts]. I'm not sure if we have more places with TS tests.
I also made a small update to the docs, but I'm sure it can be improved.

Note: I needed to rebase this branch to pass on CI.

[alexcrichton]

Thanks!

[ishitatsuyuki]

I think this regressed some part of processing somehow. I still haven't reduced a reproduction from my private codebase, but meanwhile here's the panic stacktrace I get:

thread 'main' panicked at 'assertion failed: mid <= self.len()', crates/cli-support/src/decode.rs:43:27
stack backtrace:
   0: rust_begin_unwind
             at /rustc/28b891916d4c85cd10fb2e9cfa8bc836a2c459f3/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/28b891916d4c85cd10fb2e9cfa8bc836a2c459f3/library/core/src/panicking.rs:142:14
   2: core::panicking::panic
             at /rustc/28b891916d4c85cd10fb2e9cfa8bc836a2c459f3/library/core/src/panicking.rs:48:5
   3: <&str as wasm_bindgen_cli_support::decode::Decode>::decode
   4: <alloc::vec::Vec<T> as wasm_bindgen_cli_support::decode::Decode>::decode
   5: <wasm_bindgen_cli_support::decode::Program as wasm_bindgen_cli_support::decode::Decode>::decode
   6: wasm_bindgen_cli_support::wit::process
   7: wasm_bindgen_cli_support::Bindgen::generate_output
   8: wasm_bindgen_cli_support::Bindgen::generate
   9: wasm_bindgen::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Reverting the merge commit makes things working again.

[ishitatsuyuki]

Nevermind, looks like it's just a schema breaking change and I need to align my project's dependency to the git version too.