Ingvar Stepanyan
Ingvar Stepanyan
> The Rust Exports section is where you declare how JS can access Rust code. Not really, as the name of the actual page says, it's the documentation of the...
> so far refer to singleton instances that get exported from js code No they don't? JS doesn't export anything, these are imports from global JS scope (or anywhere else)....
For clarity, this issue should probably be rephrased that it's specifically for passing `Option` with references. By-value consumption and returns are already implemented and work as expected (as your last...
@fjarri That table is for `Result` specifically. Like for other types in that section, what it means is that `Option` is not supported in params (I admit, it's confusing though,...
That said, [here](https://rustwasm.github.io/docs/wasm-bindgen/reference/types/exported-rust-types.html) it should certainly be marked as supported in both params and returns.
> But honestly, I don't see a point in bringing that specific bit of Rust semantics into JS which misses all the other parts that work together with it, like...
Because JS object is merely a wrapper for Rust one. It doesn't have a copy of the struct or something like that, it's just a pointer to the Rust side....
If you want JS side to have proper JS objects that are merely copies of the Rust ones, it might be that you want Serde integration instead (e.g. check out...
Can this be made work with vcpkg (`vcpkg install zlib-ng:wasm32-emscripten`)? Currently, even if I point it to your fork, it still fails due to trying to include the CPUID assembly...
This is what I'm seeing in the logs when vcpkg is configuring it: ``` -- Arch not recognized, falling back to cmake arch: 'x86' -- Basearch 'x86' not recognized, defaulting...