| 87d1730b | 27-Oct-2025 |
Alex Crichton <[email protected]> |
Supply type information in `func_new` for components (#11944)
Originally the `Linker::func_new` type for components was modeled after core wasm where a type was provided when the type was defined. T
Supply type information in `func_new` for components (#11944)
Originally the `Linker::func_new` type for components was modeled after core wasm where a type was provided when the type was defined. This was difficult, however, because there's no way to construct types right now and instead a component had to be created and compiled to acquire type information from it. Later various refactorings meant that it was possible to drop the type information entirely from `func_new` meaning that it was "typeless" in a sense, and the functionality relied on the tagged nature of `Val` which always knows its type.
This has proven a bit difficult to integrate into Python in some work I've been doing. Namely in Python component values are (at least IMO) best represented as native Python values where possible. Native Python doesn't distinguish, however, between integer bit widths (or signededness). This means that converting a Python value to a component value requires type information to guide the conversion process. Currently when defining a function in a linker there's no way to get at this type information meaning that the types would need to be supplied in Python, bringing up the same shortcomings of not being able to create types.
In lieu of filling out type constructors, which is itself quite nontrivial, I've opted to do the next-most-easiest thing which is to supply the type to the callee when an import is invoked. This means that the callee has all the type information necessary. While this is somewhat costly in that it clones a few arcs it's expected to be a drop in the bucket compared to the inefficiencies of `Val` so it's at least in the same spirit of the cost of the API right now.
My intention is to use this to update the C API for components and eventually end up with type information when Python is invoked in wasmtime-py. Also while I'm using wasmtime-py as a motivating case here that's sort of just one example of a host embedding which doesn't have the full fidelity of Rust's type system and might benefit from this.
show more ...
|