Wasmtime GitHub notifications bot (Mar 07 2024 at 23:11): Wasmtime GitHub notifications bot (Mar 07 2024 at 23:11):alexcrichton requested dicej for a review on PR #8062.
Wasmtime GitHub notifications bot (Mar 07 2024 at 23:11):alexcrichton requested wasmtime-core-reviewers for a review on PR #8062.
Wasmtime GitHub notifications bot (Mar 07 2024 at 23:11):alexcrichton opened PR #8062 from alexcrichton:untyped-val to bytecodealliance:main:
This commit is a large refactor of the
Valtype as used with components to remove inherent type information present currently. TheValtype is now only an AST of what a component model value looks like and cannot fully describe the type that it is without further context. For example enums only store the case that's being used, not the full set of cases.The motivation for this commit is to make it simpler to use and construct
Val, especially in the face of resources. Some problems solved here are:
With resources in play managing type information is not trivial and can often be surprising. For example if you learn the type of a function from a component and the instantiate the component twice the type information is not suitable to use with either function due to exported resources acquiring unique types on all instantiations.
Functionally it's much easier to construct values when type information is not required as it no longer requires probing various pieces for type information here and there.
API-wise there's far less for us to maintain as there's no need for a type-per-variant of component model types. Pieces now fit much more naturally into a
Valshape without extra types.Functionally when working with
Valthere's now only one typecheck instead of two. Previously a typecheck was performed first when aValwas created and then again later when it was passed to wasm. Now the typecheck only happens when passed to wasm.It's worth pointing out that
Valas-is is a pretty inefficient representation of component model values, for example flags are stored as a list of strings. While semantically correct this is quite inefficient for most purposes other than "get something working". To that extent my goal is to, in the future, add traits that enable building a custom user-definedVal(of sorts), but still dynamically. This should enable embedders to opt-in to a more efficient representation that relies on contextual knowledge.<!--
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 (Mar 07 2024 at 23:11):alexcrichton requested fitzgen for a review on PR #8062.
Wasmtime GitHub notifications bot (Mar 08 2024 at 01:03):github-actions[bot] commented on PR #8062:
Subscribe to Label Action
cc @fitzgen, @peterhuene
<details>
This issue or pull request has been labeled: "fuzzing", "wasmtime:api"Thus the following users have been cc'd because of the following labels:
- fitzgen: fuzzing
- peterhuene: wasmtime:api
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 (Mar 08 2024 at 01:22):lann submitted PR review.
Wasmtime GitHub notifications bot (Mar 08 2024 at 15:33):fitzgen submitted PR review:
LGTM!
Wasmtime GitHub notifications bot (Mar 08 2024 at 15:59):fitzgen merged PR #8062.
Last updated: Nov 22 2024 at 16:03 UTC