Stream: git-wasmtime

Topic: wasmtime / issue #9294 wasmtime-component-bindgen creates...

Wasmtime GitHub notifications bot (Sep 23 2024 at 20:40):

parasyte added the bug label to Issue #9294.

Wasmtime GitHub notifications bot (Sep 23 2024 at 20:40):

parasyte opened issue #9294:

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?

Wasmtime GitHub notifications bot (Sep 23 2024 at 21:28):

alexcrichton commented on issue #9294:

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.

Wasmtime GitHub notifications bot (Sep 23 2024 at 21:49):

parasyte commented on issue #9294:

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.

Wasmtime GitHub notifications bot (Dec 02 2024 at 07:09):

vados-cosmonic commented on issue #9294:

Hey @parasyte a bit late here, but were you able to get past this?

Wasmtime GitHub notifications bot (Dec 02 2024 at 07:17):

parasyte commented on issue #9294:

Yes. I still don't think the default should be creating an unusable zero-variant enum, though.

Wasmtime GitHub notifications bot (Dec 02 2024 at 07:21):

vados-cosmonic commented on issue #9294:

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!

Wasmtime GitHub notifications bot (Dec 02 2024 at 16:15):

parasyte commented on issue #9294:

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.

Wasmtime GitHub notifications bot (Dec 02 2024 at 18:06):

vados-cosmonic commented on issue #9294:

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 ?

Last updated: Dec 23 2024 at 12:05 UTC