feat: add more types to polyfill wasmtime in js

[zimond]

Hey I came across this project and I really like the idea. Here are some rough code I wrote to polyfill more wasmtime types and logic in wasm-bridge. Feel free to use or discard them or discuss the concept with me.

The main change to your design is that Caller now stores a Store so it could impl the AsContext / AsContextMut traits.

Have a nice day, friend.

[kajacx]

Hello, has a lot of feature at once, I think I will "split" it into separate code changes and push them one at a time.

• Memory write & read - this was on the to-do list, thanks for coming up with something that works
• Caller store rework - this is something where I was not happy with the current solution. I will have to look into your approach more closely to compare the differences
• Untyped functions and the Val type - this is something I was aware of, but honestly, I cannot really imagine why someone would choose to use untyped function over typed ones on purpose. Oh well, if you want to use it, I will re-check the code, add the tests and merge it in.
• Remove the lifetime from TypedFunction - This I simply never got too. You don't need the instance in the TypedFunction at all (can use undefined as context), but you need to "persist" the imported functions somehow. Perhaps cloning the Rc<[DropHandle]> into the exported functions could work.

[zimond]

Thanks for the write up. I removed the lifetime from TypedFunction because I am using a quite common pattern to alloc & free WASM memory, which could be found at https://radu-matei.com/blog/practical-guide-to-wasm-memory/#passing-arrays-to-rust-webassembly-modules.

So to use this pattern, the WASM module need to export two functions, one for memory alloc & one for memory free. So I need to store the typed functions of them somewhere. If the lifetime exists, it could barely be done because it's not 'static

Untyped functions are related to the plugin system I'm making. Since it is a plugin system, a plugin could provide APIs which are dynamic and not known at compile time.

[kajacx]

a plugin could provide APIs which are dynamic and not known at compile time.

Yea that's true. I want to use this for plugins as well, and when one plugin wants to call a custom function from another plugin, there is no getting around dynamic values at that point.

I removed the lifetime from TypedFunction

Great. I have already implemented that, you can look here

I think I will re-implement all the features, since I will always be adding a failing tests first. That means you will not be in the git history, is that ok?

[zimond]

It’s fine.

[kajacx]

It is probably more "correct" to "propagate" the same engine into the Caller like this, but the Engine struct is completely unused and is only there for compatibility with wasmtime, so I think it would just needlessly bloat the code.

[zimond]

Engine is used to construct the store in caller, which leads to impl AsContext and AsContextMut for Caller

[kajacx]

Ok @zimond , I think I have implemented all the changes. You can clone the repo at the current commit, or use a git dependency to verify. If there are any holes/mistakes, let me know.