Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35): Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35):alexcrichton opened PR #11944 from alexcrichton:func-new-type to bytecodealliance:main:
Originally the
Linker::func_newtype 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 fromfunc_newmeaning that it was "typeless" in a sense, and the functionality relied on the tagged nature ofValwhich 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
Valso 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.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35):alexcrichton requested wasmtime-fuzz-reviewers for a review on PR #11944.
Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35):alexcrichton requested wasmtime-core-reviewers for a review on PR #11944.
Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35):alexcrichton requested fitzgen for a review on PR #11944.
Wasmtime GitHub notifications bot (Oct 26 2025 at 12:35):alexcrichton requested wasmtime-default-reviewers for a review on PR #11944.
Wasmtime GitHub notifications bot (Oct 26 2025 at 13:44):github-actions[bot] commented on PR #11944:
Subscribe to Label Action
cc @fitzgen
<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:api", "wasmtime:c-api"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Oct 27 2025 at 16:30):pchickey submitted PR review.
Wasmtime GitHub notifications bot (Oct 27 2025 at 22:06):alexcrichton merged PR #11944.
Last updated: Dec 06 2025 at 06:05 UTC