implement "part 1" of WIT Templates

[dicej]

Per WebAssembly/component-model#172, this implements "part 1" of WIT templates, allowing WIT files to define interfaces which contain a single wildcard function, which worlds may import or export.

I've taken a "minimalist" approach to this, such that the host binding generator just skips wildcards entirely, leaving it to the host to use dynamic APIs to reflect on the component and do the necessary func_wrap (for imports) and typed_func (for exports) calls directly.

This adds two new functions to the public API:

• Component::names: provides an iterator over the names of the functions imported by the specified instance.
• ExportInstance::funcs: provides an iterator over the names of the functions exported by this instance.

In both cases, I'm open to alternative API designs for getting that information.

Note that I've added a temporary dependency override to Cargo.toml, pointing to our fork of wasm-tools, which includes the necessary wit-parser changes. We're still iterating on that and will PR those changes separately. We also have a fork of wit-bindgen with a new "wildcards" test to verify everything works end-to-end: bytecodealliance/wit-bindgen@main...dicej:wit-templates. I'll PR that last once everything else is stable.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[alexcrichton]

I think the extra accessors here are fine, but reading over the test it leaves me with the impression of "why use bindgen!?" in the sense that if the *-imports are skipped then there's not actually any usage of the types in the test here. I do think though that for more complex types at least having the types generated is useful. You also mention that this is a first step, but is this intended to be iterated further on to integrate the *-imports into the codegen process?

[dicej]

Yes, in that particular test case, the only reason I used bindgen! was to ensure that it doesn't choke on wildcards. In a more realistic scenario, a world could contain a mix of non-wildcard interfaces and wildcard interfaces. You'd still want generated bindings for the former even if you don't need them for the latter.

Also, although WebAssembly/component-model#172 does not include "mixed" interfaces which contain both wildcard and non-wildcard functions, it would be pretty trivial to add support for that. For example:

default world wildcards {
    import imports: interface {
        *: func() -> u32
        foo: func(s: string) -> string
        bar: func() -> u32
    }
}

BTW, my initial implementation (#5925) did generate code for wildcards, but that code ended up just being wrappers around the Wasmtime API which didn't add much value vs. using the API directly. If you think there is value to be added via code generation, we can revisit that.

[alexcrichton]

In some sense the whole bindgen! macro is a pretty thin wrapper around the component embedding API, but I think the main value from it is that it gets all the types right and you don't have to think about it. From another perspective any type-level bugs are caught by rustc and aren't logic bugs in your own code. Manually calling linker functions, though, you can get past rustc but accidentally deviate from the *.wit which I think is nice to fix if we can. More-or-less I do think that it's wortwhile to generate typed bindings to *-imports/exports to make it idomatic with the rest of *.wit-generated bindings and otherwise make it so you don't have to think about the types.

[dicej]

Fair enough. Would you mind taking a look at the diff for #5925 and provide feedback on that, then? I can close this PR and reopen that one if desired. I just want to make sure we're aligned about what the generated code should look like first.

[alexcrichton]

For sure yeah, the main thing I'd consider on #5925 is sort of along the same lines of catching issues earlier rather than later. There it looks like the strategy is that *-imports bottom out into a fn call(&mut self, name: &str, ...) trait method but an alternative would be for the host to pass in some sort of configuration "I support call with these names" which then fails instantiation if enough names weren't supplied. My original idea here was to pass in a vector of named trait objects, but that may be too inefficient for the intended use cases (I'm not sure).

I don't feel super strongly about this particular point though myself. It feels a little odd to pass around the component when you're adding something to a linker but that's probably just me needing to get over my preconceptions about this. In any case I do think that #5925 is better in the sense of "everything is type-checked for you" so I think that would be a better starting point than not generating bindings for *

[dicej]

@alexcrichton I've implemented code generation per your feedback. Please let me know what you think.

[alexcrichton]

Looks reasonable to me! I'm not necessarily totally wild about the design but I can't think of alternatives that I like better either. The WildcardMatches struct feels a bit clunky and makes me sort of want a builder-style for creating imports where you can iteratively add more wildcard imports, but I don't know how that would actually work off the top of my head.

[dicej]

@alexcrichton Thanks for all your feedback. I think I've addressed everything so far.

[alexcrichton]

Looks good to me!

(approving but we'll naturally want to wait for the wasm-tools suite of crates to be published first before actually merging)