Wasmtime GitHub notifications bot (Mar 21 2025 at 10:29): Wasmtime GitHub notifications bot (Mar 21 2025 at 10:29):pimeys added the bug label to Issue #10449.
Wasmtime GitHub notifications bot (Mar 21 2025 at 10:29):pimeys opened issue #10449:
Test Case
In our repository, we have versioned wit shared by our host and guest code. One of the bindgen calls started generating invalid Rust code when we updated wasmtime from version 30 to version 31:
Then again the next version of this wit, which is just reorganized and a few things are changed in the method calls, this generates correct code:
Steps to Reproduce
- Clone repo https://github.com/grafbase/grafbase
- Compile the crate crates/wasi-component-loader with cargo build, it should work.
- Change the branch to renovate/wasmtime which updates wasmtime from 30 to 31
- See the bindgen macro giving an error: use of undeclared lifetime name 'a
Expected Results
Updating wasmtime should not lead to invalid Rust code.
Actual Results
If you expand the macro with an error, we see code like this generated:
pub type DirectiveSite = super::super::super::__with_name0::DirectiveSite<'a>; pub type FieldDefinitionDirective = super::super::super::__with_name0::FieldDefinitionDirective<'a>;The 0.9.0 wit macro does not generate code like this, nor does wasmtime 30 for the exact same macro call.
Versions and Environment
Wasmtime: 31.0.0
Operating system: Aurora Linux
Architecture: x86_64
Wasmtime GitHub notifications bot (Mar 21 2025 at 10:38):pimeys commented on issue #10449:
This looks like the source of the issue:
https://github.com/bytecodealliance/wasmtime/pull/10311
Ping @pchickey
Wasmtime GitHub notifications bot (Mar 21 2025 at 18:13):pchickey commented on issue #10449:
Thanks for the bug report - will look into this soon
Wasmtime GitHub notifications bot (Mar 21 2025 at 18:13):pchickey assigned pchickey to issue #10449.
Wasmtime GitHub notifications bot (Apr 23 2025 at 10:40):pimeys commented on issue #10449:
Is the fix for this included in the latest release? https://github.com/bytecodealliance/wasmtime/releases/tag/v32.0.0
Wasmtime GitHub notifications bot (May 07 2025 at 13:09):fbjork commented on issue #10449:
@pchickey is this issue fixed?
Wasmtime GitHub notifications bot (May 07 2025 at 17:21):pchickey commented on issue #10449:
Hi - sorry, this fell off my radar, no its not fixed. I will try to get to it but I'm on vacation for the second half of May so I'm working to finish other projects before then.
Wasmtime GitHub notifications bot (May 08 2025 at 16:30):alexcrichton added the wasm-proposal:component-model label to Issue #10449.
Wasmtime GitHub notifications bot (May 08 2025 at 16:30):alexcrichton assigned alexcrichton to issue #10449.
Wasmtime GitHub notifications bot (May 08 2025 at 16:30):alexcrichton unassigned pchickey from issue #10449.
Wasmtime GitHub notifications bot (May 10 2025 at 00:28):alexcrichton commented on issue #10449:
@pimeys or @fbjork would one of y'all be up for reducing this down to something smaller? If you can get a reproduction that's just wasmtime + some wits + some bindgen! calls I can probably take it from there
Wasmtime GitHub notifications bot (May 16 2025 at 14:05):pimeys commented on issue #10449:
Ok, so this took me a while (been quite busy too), but here's a reproduction:
https://github.com/pimeys/wasmtime-regression-poc
You can change wasmtime to version 30 and it compiles. This is not the only lifetime error I've witnessed... There's also cases when the macro renders something like
pub type MeowMeow: &'a __with_name0::MeowMeow;and I've also seen
pub type MeowMeow: __with_name0::MeowMeow<'a>;all wrong. The correct way to expand this would be:
pub type MeowMeow<'a> = __with_name0::MeowMeow<'a>;If you want more examples, you have to dig into our big codebase and update wasmtime there. Hopefully this repro is enough though.
Wasmtime GitHub notifications bot (May 18 2025 at 22:22):alexcrichton commented on issue #10449:
Could you expand on how
pub struct MeowMeow<'a>is generated. I'm assuming it's generated by a separatebindgen!invocation as opposed to hand written, but if it's hand-written that may also explain the mismatch here. In any case I'm basically curious to dig into the provenance of this definition and from whence it came.
Wasmtime GitHub notifications bot (May 19 2025 at 07:09):pimeys commented on issue #10449:
Could you expand on how
pub struct MeowMeow<'a>is generated. I'm assuming it's generated by a separatebindgen!invocation as opposed to hand written, but if it's hand-written that may also explain the mismatch here. In any case I'm basically curious to dig into the provenance of this definition and from whence it came.It is hand-written in these certain types. We try to avoid extra allocations in certain very hot paths. Therefore we have types with a lifetime parameter, allowing us only allocate once when going from the host to the guest.
Wasmtime GitHub notifications bot (May 19 2025 at 17:28):alexcrichton commented on issue #10449:
Ah ok that's likely where this issue is coming from. The
bindgen!macro is pretty opinionated about how ownership should work, but the rawwasmtimecrate itself is less opinionated. If possible for the performance-sensitive situation can you use thewasmtimecrate directly?
Wasmtime GitHub notifications bot (May 19 2025 at 19:15):pimeys commented on issue #10449:
I think we wanted to avoid that because we got a _ton_ of boilerplate to write before. We started using the macro to cut down a lot of code we were writing before. And, this used to work just fine two versions ago, then broke in version 31. Do you think it's too tricky of a fix? If it already renders type aliases, it should be fine to add the lifetimes to the generated code, no?
Wasmtime GitHub notifications bot (May 19 2025 at 20:03):alexcrichton commented on issue #10449:
The hard part is that the bindings generator can generate types in multiple various modes, but in this situation where a type isn't actually used there's no way to control how these types are generated. In version 31 unused types started generated bindings which is where this is coming up.
Assuming the type is unused in the WIT for your codebase could you have a dummy definition without a lifetime? That way the unused type wouldn't actually end up getting used anywhere and the "real" definition would have lifetimes?
Wasmtime GitHub notifications bot (May 20 2025 at 06:02):pimeys commented on issue #10449:
The hard part is that the bindings generator can generate types in multiple various modes, but in this situation where a type isn't actually used there's no way to control how these types are generated. In version 31 unused types started generated bindings which is where this is coming up.
Assuming the type is unused in the WIT for your codebase could you have a dummy definition without a lifetime? That way the unused type wouldn't actually end up getting used anywhere and the "real" definition would have lifetimes?
Wait. Now I get it. These types are not used anymore anywhere in the WIT. Jesus, I can fix this right now easily. We have this set of versioned WIT in our system to never break backwards compatibility, and I missed totally that we don't really need these types at all.
Yeah, let me fix this on our end, when the tests are green I can close the issue. Thank you!
Wasmtime GitHub notifications bot (May 20 2025 at 06:33):pimeys closed issue #10449:
Test Case
In our repository, we have versioned wit shared by our host and guest code. One of the bindgen calls started generating invalid Rust code when we updated wasmtime from version 30 to version 31:
Then again the next version of this wit, which is just reorganized and a few things are changed in the method calls, this generates correct code:
Steps to Reproduce
- Clone repo https://github.com/grafbase/grafbase
- Compile the crate crates/wasi-component-loader with cargo build, it should work.
- Change the branch to renovate/wasmtime which updates wasmtime from 30 to 31
- See the bindgen macro giving an error: use of undeclared lifetime name 'a
Expected Results
Updating wasmtime should not lead to invalid Rust code.
Actual Results
If you expand the macro with an error, we see code like this generated:
pub type DirectiveSite = super::super::super::__with_name0::DirectiveSite<'a>; pub type FieldDefinitionDirective = super::super::super::__with_name0::FieldDefinitionDirective<'a>;The 0.9.0 wit macro does not generate code like this, nor does wasmtime 30 for the exact same macro call.
Versions and Environment
Wasmtime: 31.0.0
Operating system: Aurora Linux
Architecture: x86_64
Wasmtime GitHub notifications bot (May 20 2025 at 06:33):pimeys commented on issue #10449:
Yep. Thank you for your patience. I can close this issue now. It kind of put me a bit off the rails because the error was a bit weird that I didn't see we actually didn't use these types anywhere in the code.
Last updated: Dec 13 2025 at 19:03 UTC