bytecodealliance
wasmtime-component-bindgen creates unusable zero-variant enums for resources
Test Case
use wasmtime::component::bindgen;
bindgen!({
// WIT from https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#package-format
// Amendment: added the `world local` section to make bindgen happy.
inline: "
package local:demo;
interface types {
resource file {
read: func(off: u32, n: u32) -> list<u8>;
write: func(off: u32, bytes: list<u8>);
}
}
interface namespace {
use types.{file};
open: func(name: string) -> file;
}
world local {
export namespace;
}
",
include_generated_code_from_file: true,
});
fn main() {}
Steps to Reproduce
bindgen! generates a zero-variant enum for each resource in a WIT. I.e. the type is impossible to instantiate. To verify I'm not insane, I tried using a WIT from documentation, which is shown above, and the source of the WIT is the linked documentation.
The Rust code output by bindgen includes:
pub enum File {}
A File cannot be instantiated, so how is the namespace.open() function supposed to return one? And for that matter, how are the File.read() and File.write() implementations supposed to accept a reference to a File that can't be created?
This never type is created here:
https://github.com/bytecodealliance/wasmtime/blob/eb0428ebadf90429c167ec29e9bb25252de85acc/crates/wit-bindgen/src/lib.rs#L1634
Expected Results
I would like the ability to construct the resources I'm defining in WIT.
Actual Results
File cannot be constructed.
Versions and Environment
Wasmtime version or commit: 25.0.0
Operating system: Windows 11
Architecture: x86_64
Extra Info
Shouldn't this be a compile time error instead of an unusable type?
Thanks for the report! This example in the documentation might help you here, the key thing being the with key indicating your own type to use instead of the empty enum type.
This is something where the defaults of bindgen! aren't great where we should probably require with: { ... } by default rather than generating this empty enum which is more-or-less unusable.
That could be exactly what I'm missing! I saw the other code path in bindgen! that imports an existing type by path but had no idea how to trigger it.
Yes. I still don't think the default should be creating an unusable zero-variant enum, though.
My understanding that the zero variant enum was there because there's just not much else that "makes sense" if the resource isn't being implemented by the embedding/bindgen target -- resources do not have a generic representation/transmission or even identification mechanism outside of the embedder (whether guest or host) that defines them.
What would you suggest instead? Maybe there's a better default to have!
Raise an error with an appropriate suggestion. Such as "Did you meant to use with { ... }?" and link to relevant documentation.
That would be a much better experience than the bindgen! macro seemingly being accepted, but then you can't make any further progress.
Ah yeah that would be much more ergonomic, so maybe rather than generating the struct we could add in a compile_error if we hit this case -- would you be open to submitting that improvement to wit-bindgen ?