0.12 js-component-bindgen release has bugs

[WIGGLES-dev]

I was playing around with the new p3 async capabilities of wit-bindgen and I ran headfirst into issues with anything that relies on async.

See the repro here

1. async keyword in wit leads to missing .d.ts definitions,
   for instance hello: async func() -> string; export type hello() -> String; but the real definition is asyncHello() -> Promis

2. simple async function returning string fails because of undefined helper (run the repro of ayncHello) it will give you vals is undefined because code generation is broken

3. async resource handling is broken for multiple reasons

3A) methods defined with async in wit lead to code generation of a class that if you can use I have no idea how to (instead of the normal async method you would expect) ~ see code generation of asyncMethodCounterDec and lack of counter.prototype.dec

3B) following up on 3B, you can internally define a method as async and its still broken see #counter.internal-async-dec and #counter.internal-async-dec-n and this is where I suspect resource handles aren't being properly transffered. What you can observe in the trace is a wit-bindgen doing a null pointer dereference (make sure you follow build instructions for debug to make this clear)

thread '<unnamed>' (1) panicked at src\lib.rs:3:1:
null pointer dereference occurred [cli.js:74:17](http://localhost:5174/node_modules/@bytecodealliance/preview2-shim/lib/browser/cli.js)
    write cli.js:74
    blockingWriteAndFlush io.js:138
    trampoline16 jco_async_transpile_repro.js:1031
    fixups jco_async_transpile_repro.js line 789 > WebAssembly.compile:0
    flush jco_async_transpile_repro.js line 789 > WebAssembly.compile:150
    _ZN4wasi7imports4wasi2io7streams12OutputStream24blocking_write_and_flush17h698c3e65ebef37eaE jco_async_transpile_repro.core.wasm:141858
    _ZN3std2io5Write9write_all17h57b8f46fbf413d6dE jco_async_transpile_repro.core.wasm:129265
    _ZN3std9panicking12default_hook28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17h2462c4378aad4d62E jco_async_transpile_repro.core.wasm:137404
    _ZN3std9panicking12default_hook28_$u7b$$u7b$closure$u7d$$u7d$17h612830929f00a0e6E jco_async_transpile_repro.core.wasm:136181
    _ZN3std9panicking12default_hook17h2eebd4aa18774fd9E jco_async_transpile_repro.core.wasm:135770
    _ZN3std9panicking15panic_with_hook17h0b56c12c5cf9d8b7E jco_async_transpile_repro.core.wasm:135090
    _ZN3std9panicking13panic_handler28_$u7b$$u7b$closure$u7d$$u7d$17h728f68a4e07433b5E jco_async_transpile_repro.core.wasm:133333
    _ZN3std3sys9backtrace26__rust_end_short_backtrace17h61900e6958afddeeE jco_async_transpile_repro.core.wasm:126952
    _RNvCskz7dRiVr1hn_7___rustc17rust_begin_unwind jco_async_transpile_repro.core.wasm:126940
    _ZN4core9panicking18panic_nounwind_fmt17hb808206c733c40d7E jco_async_transpile_repro.core.wasm:171542
    _ZN4core9panicking30panic_null_pointer_dereference17h5711ceca0a72cdbfE jco_async_transpile_repro.core.wasm:171640
    _ZN25jco_async_transpile_repro7exports5repro9jco_async4test13CounterBorrow3get17h21d6ca8f0d0af2daE jco_async_transpile_repro.core.wasm:15948
    _ZN25jco_async_transpile_repro7exports5repro9jco_async4test40_export_method_counter_internal_dec_cabi28_$u7b$$u7b$closure$u7d$$u7d$17hd93c17e9c3fbe758E jco_async_transpile_repro.core.wasm:19111
    Future$GT$4poll17hb14d87eb8cb94333E jco_async_transpile_repro.core.wasm:113994
    Stream$GT$9poll_next17h19c7674ae35d4374E jco_async_transpile_repro.core.wasm:72971
    _ZN12futures_util6stream6stream9StreamExt15poll_next_unpin17h4af2365e6e2288f9E jco_async_transpile_repro.core.wasm:79867
    _ZN11wit_bindgen2rt13async_support11FutureState4poll28_$u7b$$u7b$closure$u7d$$u7d$17h6a12ab44723793c1E jco_async_transpile_repro.core.wasm:76483
    _ZN11wit_bindgen2rt13async_support11FutureState16with_p3_task_set17h834c7e64d9b043c5E jco_async_transpile_repro.core.wasm:76324
    _ZN11wit_bindgen2rt13async_support11FutureState4poll17hc6d6e3a72a18c69fE jco_async_transpile_repro.core.wasm:79741
    _ZN11wit_bindgen2rt13async_support11FutureState8callback17h4efa2a5764da5ae9E jco_async_transpile_repro.core.wasm:80384
    _ZN11wit_bindgen2rt13async_support8callback17h7dfb4ac3b8a744c5E jco_async_transpile_repro.core.wasm:81200
    _ZN11wit_bindgen2rt13async_support10start_task17hde5553e457d8b1d2E jco_async_transpile_repro.core.wasm:10059
    _ZN25jco_async_transpile_repro7exports5repro9jco_async4test40_export_method_counter_internal_dec_cabi17he8f5a960d9a23133E jco_async_transpile_repro.core.wasm:18985
    dec jco_async_transpile_repro.core.wasm:11318
    internalDec jco_async_transpile_repro.js:1451
    <anonymous> index.ts:39
    showTest index.ts:7
    <anonymous> index.ts:36

the above stack trace can be linked back to this snippet (which is in the repro and can be reproduced cargo expand and npm run expand)

   impl<'a> CounterBorrow<'a> {
                    #[doc(hidden)]
                    pub unsafe fn lift(rep: usize) -> Self {
                        Self {
                            rep: rep as *mut u8,
                            _marker: core::marker::PhantomData,
                        }
                    }
                    /// Gets access to the underlying `T` in this resource.
                    pub fn get<T: GuestCounter>(&self) -> &T {
                        let ptr = unsafe { &mut *self.as_ptr::<T>() };
                        ptr.as_ref().unwrap()
                    }
                    fn as_ptr<T: 'static>(&self) -> *mut _CounterRep<T> {
                        Counter::type_guard::<T>();
                        self.rep.cast()
                    }
                }

So I can only assume that any async code does not handle passing resource handles properly

I think the only thing that works is a top level async function that takes only scalar arguments and returns scalar arguments, but this is not a comprehensive test suite.

Also, feel free to use this as a basis for any kind of test suite for generated bindings

[vados-cosmonic]

Thanks for submitting this issue @WIGGLES-dev ! currently the async support in Jco is still very experimental and as you've found, has bugs. I'll look into this issue along with the other tests and implementation work that is still underway.