You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am using fp-bindgen to create bindings for a wasm plugin that I wrote in Rust.
The flow is that I create a protocol then export a plugin and a rust-wasmer-wasi runtime. I use the plugin to generate bindings for my wasm plugin and use the runtime to import the wasm module into Rust and test out the exported functions.
Also just incase this is relevant, I am importing the latest fp-bindgen version from the git main branch.
Issue Description:
When using the RustWasmerWasiRuntime option. The created bindings.rs file contains a Runtime impl with a fn new() function to initialize it. That function has this line:
let env_from_instance = RuntimeInstanceData::from_instance(&mut store, &instance);
The from_instancefunction checks that the three functions are exported from the WASM module:
__fp_free
__fp_guest_resolve_async_value
__fp_malloc
By default, when you use the RustPlugin with no dependencies it will add fp-bindgen-support with the guest feature as as dependecny as part of the generated rust-plugin crate. This however, only exports the __fp_free and __fp_malloc as the guest feature is enabled. The __fp_guest_resolve_async_value is left out because the async feature is not enabled. This will in turn break the line of code I referenced above and usage of the generated rust-wasmer-wasi-runtime bindings will break.
Therefore, you have to add fp-bindgen-support as a CargoDependency as part of the dependencies option for the RustPlugin and add async as a dependency manually. I am not sure if this is the intended behavior but it seems a bit odd as if all those three functions are expected to be exported by default when generating the RuntimeInstanceData.
Happy to provide more info, apologies if I missed something in the docs!
The text was updated successfully, but these errors were encountered:
Thanks for the report! I'll have to confirm this, but it sounds like the plugin generator correctly leaves out the async feature when the protocol doesn't contain any async functions, whereas the runtime generator doesn't correctly disable the check in that case. This would be definitely something we'll need to fix.
Hello!
Background:
I am using fp-bindgen to create bindings for a wasm plugin that I wrote in Rust.
The flow is that I create a protocol then export a plugin and a rust-wasmer-wasi runtime. I use the plugin to generate bindings for my wasm plugin and use the runtime to import the wasm module into Rust and test out the exported functions.
Also just incase this is relevant, I am importing the latest
fp-bindgen
version from the git main branch.Issue Description:
When using the
RustWasmerWasiRuntime
option. The createdbindings.rs
file contains aRuntime
impl with afn new()
function to initialize it. That function has this line:let env_from_instance = RuntimeInstanceData::from_instance(&mut store, &instance);
The
from_instance
function checks that the three functions are exported from the WASM module:__fp_free
__fp_guest_resolve_async_value
__fp_malloc
By default, when you use the
RustPlugin
with nodependencies
it will addfp-bindgen-support
with theguest
feature as as dependecny as part of the generatedrust-plugin
crate. This however, only exports the__fp_free
and__fp_malloc
as theguest
feature is enabled. The__fp_guest_resolve_async_value
is left out because theasync
feature is not enabled. This will in turn break the line of code I referenced above and usage of the generatedrust-wasmer-wasi-runtime
bindings will break.Therefore, you have to add
fp-bindgen-support
as aCargoDependency
as part of thedependencies
option for theRustPlugin
and addasync
as a dependency manually. I am not sure if this is the intended behavior but it seems a bit odd as if all those three functions are expected to be exported by default when generating theRuntimeInstanceData
.Happy to provide more info, apologies if I missed something in the docs!
The text was updated successfully, but these errors were encountered: