Massimiliano Mantione (Sep 02 2025 at 14:46): Massimiliano Mantione (Sep 02 2025 at 14:46):I am defining and hosting a component, everything is in Rust, I use wit-bindgen for the boilerplate as described in the docs and everything works fine.
The component has both imported and exported interfaces, and the host implements the imported ones.
However, there is a thing I need to do that is blocking me: inside hosted functions, I need to manipulate the available fuel (using get_fuel and set_fuel on the store).
The problem is that the "hosted object" (the T in the Store<T>) cannot access the store, and I did not find a way to expose it.
If I did all the bindings by hand I think I could do what I need, using the Caller interface: the Caller would receive the call, and it could call the hosted function implementation passing the store to it.
But with the traits implemented by wit-bindgen this looks impossible to me.
And doing all the bindings by hand would be extra-annoying.
Am I missing something?
Alex Crichton (Sep 02 2025 at 14:56):It's correct that you can't access the store with default bindings, yes. The eventual end goal, however, is to support the store flag to imports/exports when generating bindings on the Wasmtime side of things (similar to the async, trappable, tracing, etc flags). Right now if you use just store it'll probably panic as the implementation isn't filled out yet, but if you use async | store you'll have access to the store (but you'll have to use async too)
Alex Crichton (Sep 02 2025 at 14:57):basically, this is on me to write up an issue about enabling this in Wasmtime. You're otherwise not missing anything, it's not possible to do this with generated bindings. What you can do, however, is don't use the generated bindings for functions that need access to fuel (it's a difficult option to use but theoretically possible, e.g. skip bindings for certain functions)
Lann Martin (Sep 02 2025 at 16:07):As a temporary workaround you could expand the generate! macro and copy the bits you need into a manual implementation.
Massimiliano Mantione (Sep 02 2025 at 16:17):Thanks for the prompt reply!
Using async | store and I forced to use async hosted functions, or can I just keep using regular ones?
(I'll try it out, but asking is faster...)
Massimiliano Mantione (Sep 02 2025 at 16:18):@Alex Crichton
Is there an open issue about the store feature?
Alex Crichton (Sep 02 2025 at 16:19):Yes you're force to use async with async | store, and no I haven't opened an issue yet
Massimiliano Mantione (Sep 02 2025 at 16:20):As a temporary workaround you could expand the
generate!macro and copy the bits you need into a manual implementation.
I was considering editing the automatically generated bindings.
Once I freeze the wit file this might be the best compromise for now.
Is using the bindgen macro or the wit-bindgen CLI command the same thing?
Right now I am using the macro on the host side, but I could switch to the CLI command with an explicitly generated file, which then I would modify.
Does this make sense?
Alex Crichton (Sep 02 2025 at 16:21):The wit-bindgen CLI tool currently only supports guests and has no integration with Wasmtime (despite the crate in Wasmtime having the same name). So on the host you can only use bindgen! and there's no other option
Massimiliano Mantione (Sep 02 2025 at 16:23):Ok, I have already used cargo expand to navigate my way in the generated code.
I could just use that, save the file, and start from there...
For now, thanks! :pray:
Alex Crichton (Sep 02 2025 at 17:58):Ok I wrote up an issue at https://github.com/bytecodealliance/wasmtime/issues/11590
Last updated: Dec 06 2025 at 07:03 UTC