Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
support worlds which import and/or export "wildcard" interfaces
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 chosen to implement the bindings for host-implemented functions in such a way that the host may delay import resolution until the latest possible moment, i.e. when the guest is actually calling the function. This allows for fully dynamic resolution (e.g. using the function name as a key to be looked up in a remote key-value store) when desired. This does come at a small performance cost compared to doing resolution at e.g. link time instead. In cases where the host wants to do resolution earlier (e.g. at deploy or instantiation time), that's certainly possible, e.g.: ```rust let component = Component::new(&engine, wasm)?; let funcs = component .names("imports") .map(|name| Ok((name.to_owned(), my_resolver(name)?))) .collect::<Result<HashMap<_, _>>>()?; struct MyImports<F> { funcs: HashMap<String, F> } impl <F: Fn() -> Result<u32>> imports::Host for MyImports<F> { fn call(&mut self, name: &str) -> Result<u32> { (self.funcs.get(name).unwrap())() } } let mut store = Store::new(&engine, MyImports { funcs }); ... ``` If we feel that early resolution is the more common case, we could consider adding a configuration option to the binding generator which indicates whether early or late resolution is desired, allowing the generator to optimize (ergonmically and performance-wise) accordingly. Note that the generated `add_to_linker` functions now take a `&Component` parameter as well as a `&mut Linker`. This allows those functions to inspect the component in order to determine how many `func_wrap{_async}` calls to make, and with what names. I'm open to alternatives to this if there's a better way. Finally, 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. Signed-off-by: Joel Dice <[email protected]>
- Loading branch information