Hello, hope everyone's having a good day. So I've been playing around with wasmcloud and I'm "overengineering" the codegen part to get something nice. Right now, I'm dealing with some issues with using multiple generate!calls.
I'm using tons of code gen (including custom rust types that I add to the bindings using with and also the wit files themselves) where I'm doing a separate generate! call per feature (http endpoints in this case). In order to facilitate generation, I also have worlds for each feature that will be used to it's corresponding generate! section. My expectation would be then that I'd have a final, top-level world that exports all the feature interfaces and a top-level generate! that will with out to all feature bindings.
The problem, it seems like my final top-level generate! is not getting an export macro even though it's exporting interfaces that container resources in them.
This might be a bug in generate! perhaps? The with side of the guest isn't as heavily hammered on right now as the with side of a Wasmtime host. Do you have an example repo and/or a reproduction to poke around?
On it!
Hey, sorry for disappearing. Most of the issues I had seemed to disappear on the latest wit-bindgen. But I'm dealing with a new bug around the generated bindings. Specifically, I'm importing wasmcloud:postgres's interface/wit/provider (not sure what the right term is) but wit-bindgen doesn't seem to map them correctly to rust. Building it for wasm32-wasip2 fails with:
Caused by:
0: failed to decode world from module
1: module was not valid
2: failed to resolve import `wasmcloud:postgres/query@0.1.1-draft::[async-lower]query`
3: failed to validate import interface `wasmcloud:postgres/query@0.1.1-draft`
4: type mismatch for function `query`: expected `[I32, I32] -> [I32]` but found `[I32, I32, I32, I32, I32] -> [I32]`
Repro is avail here: https://github.com/dman-os/bad_bindigns_repro/
Should I take this issue to the wasmcloud devs? It seems like an issue with wit-bindgen to me but maybe their wit files are breaking some convention I'm not smart on.
I don't see any wit path in the second bindgen macro (line 15)
@Christof Petig that's going to default path of ./wit. And yeah, sorry, the repo contains attempts to reproduce the original issue of this thread (the secondary wit2 dir and all being analogue to a shared rust binding lib I have in my real repo). But the main issue at hand is the generated binding mismatch for wasmcloud:query@0.1.0-draft that leads to issues during the wasm-component-ld phase.
Ah I believe you're running into a case where wasm-component-ld, which is producing the component, in stable Rust is too old for this. Switching to cargo +nightly build fixes the example for me
Basically it takes time for tooling to propagate in stable Rust so if we fix things it'll take awhile to make its way to stable
Last updated: Dec 06 2025 at 07:03 UTC