bytecodealliance / bytecodealliance/wasmtime

wasmtime-component-bindgen creates unusable zero-variant enums for resources

Open
#9,294 7 comments 0 reactions 0 assignees View on GitHub
bug
Dominant language
Rust
Stars
18.6k
Forks
1.8k
Avg merge
1d 18h
Merged PRs (30d)
126

Description

### Test Case

```rust
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;
write: func(off: u32, bytes: list);
}
}

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](https://doc.rust-lang.org/reference/items/enumerations.html#zero-variant-enums) 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](https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#package-format).

The Rust code output by `bindgen` includes:

```rust
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?

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.