Ingvar Stepanyan

> As far as I know, inlining an async function call into another async function should be safe though. As long as you preserve same number of `await`s, yes (which...

@fabiosantoscode The difference is that your function now returns `42`, but the original didn't.

Hm, could be a permission issue, especially given the `/opt` in the end of your path (did you try mounting actual `/opt`? if so, I doubt the browser can access...

FWIW same issue on EOS 250D. `gphoto2 --bulb=...` doesn't work with "(0): bulb not found in configuration tree." in the logs. I'll give `eosremoterelease` a try, but would be nice...

> I had to add a new `VectorIntoJsValue` trait, since similarly to `VectorIntoWasmAbi` the orphan rule won't let us directly implement `From` for `JsValue` outside of `wasm-bindgen`. Something I was...

> the C ABI is still supposed to be a fixed ABI that matches C, not change depending on what target features are enabled Right, but C ABI that Rust...

> it only happens on `wasm32-unknown-unknown`, not other targets like `wasm32-wasi`. I suspect it might just be another accidental result of Rust [using `PassMode::Direct` where it shouldn't in `wasm32-unknown-unknown`'s C...

link_to can actually help me remove couple of manual hacks from wasm-bindgen-rayon, but only if this behaviour is preserved. Now that it exists, I'm doing something like: ```rs fn _ensure_worker_emitted()...

Another alternative would be to extend `link_to!` to allow custom wrappers around it so that devs could do `link_to!(module = "...", wrapper = "new Worker({}, {{ type: 'module' }})")` and...

It's used for emitting a Web Worker's entry point alongside the main JS - https://github.com/RReverser/wasm-bindgen-rayon/blob/a947bdce8ef1e4b5456b349bd5b3763fe2516e25/src/lib.rs#L55-L59 - which will be used via `new Worker(...)` afterwards. So that emitted file is still...