Wasmtime GitHub notifications bot (Feb 03 2025 at 17:54): Wasmtime GitHub notifications bot (Feb 03 2025 at 17:54):fitzgen added the wasmtime:api label to Issue #10176.
Wasmtime GitHub notifications bot (Feb 03 2025 at 17:54):fitzgen added the wasm-proposal:gc label to Issue #10176.
Wasmtime GitHub notifications bot (Feb 03 2025 at 17:54):fitzgen opened issue #10176:
While we provide embedder APIs for creating one-off function/array/struct types, we don't currently have a way to define a set of types inside a rec group. This means the embedder cannot define a type that has a reference to itself, or any mutually recursive types. It also means that if a Wasm module uses such a type in its imports or exports, the embedder must find it and pluck it out via
Module::{imports,exports}rather than simply create it themselves when they are trying to define functions that take/return those types.This shouldn't be hard to implement, but it will require a bit of API design work that we want to make sure we are happy with, and that we think will extend well for Wasm's likely future type system extensions, before we commit to anything.
Random, half-baked thoughts:
- I think we will probably want to use builder-style APIs.
- Would be nice if the same Rust builder types could be reused for both defining types in a custom rec group and defining one-off types.
- Would be nice to re-implement our existing
StructType::newet al Wasm type constructors in terms of these new builders.- Representing a "forward reference to a type in this rec group I haven't defined yet" will be interesting. Especially since we need to eventually validate that the type did get defined.
- Rather than using rec-group-local indices (which makes sense at the wasm binary/validation level, but doesn't provide fantastic ergonomics at the embedder API level) we could perhaps try out an API similar to working with labels in a compiler, where you declare (but do not yet define) a type and can use that to define fields in Wasm structs and all that, and then later define the type and bind that definition to the earlier declaration. Finishing the rec group builder with unbound declarations would fail to validate and return an error.
- Perhaps, for API convenience and to consolidate validation, we should wait to validate everything until the whole rec group is finished (i.e.
RecGroupBuilder::finishor whatever is called) rather than making ~every individual builder method fallible, since some things only can be validated when the rec group is complete.
Last updated: Feb 28 2025 at 03:10 UTC