You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments