1753: Use a union for VMContext for functions r=MarkMcCaskey a=MarkMcCaskey
This makes the code more self documenting and correctly uses `unsafe`
to communicate that it's the caller's responsibility to ensure that the
code paths that can lead to the access can only write the value they
expect to be there.
spun off of #1739
- [x] There's still some inconsistent use of `vmctx` and `extra_data` might be good to unify this more.
- [x] Improve docs on the new type
Co-authored-by: Mark McCaskey <mark@wasmer.io>
This makes the code more self documenting and correctly uses `unsafe`
to communicate that it's the user's responsibility to ensure that the
code paths that can lead to the access can only write the value they
expect to be there.
I believe this trait is no longer necessary since `WasmExternType` has
been moved inside the `wasmer` crate itself (this crate).
See https://github.com/wasmerio/wasmer-reborn/pull/121.
`cargo check` and `cargo test` agrees.
Also, this trait is annoying to implement abstraction over
`NativeFunc` since it is not re-exported outside of the crate.
Because `Func` needs an access to the runtime API (`wasmer-runtime`)
to trap properly, either we move parts of `wasmer-runtime` to
`wasm-common`, or we move parts of `wasm-common` into `wasmer`. I
decided to go with the second approach since `wasmer` is the only
crate to use `HostFunction` & co. It's not “common” by definition, and
it's way easier (for the moment).
`NativeFunc::call` is about 8% faster in the case we're benchmarking
by avoiding allocating a vector for the params / returns, instead we
do logic to determine which is larger and use that, conditionally
copying it back to the rets array if needed.
