Remove type information from dynamic component funcs #8070
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit removes the `&Component` argument from the `component::Linker::func_new` API. This is inspired by bytecodealliance#8062 where `Val` holds less type information as well in addition to the realization that type-checking happens at runtime rather than instantiation time. This argument was originally added to mirror `wasmtime::Linker::func_new` which takes a type argument of the core wasm function that's being defined. Unlike core wasm, though, component functions already have to carry along their type information as part of function calls to handle resources correctly. This means that when a host function is invoked the type is already known of all the parameters and results. Additionally values are already required to be type-checked going back into wasm, so there's less of a need to perform an additional type-check up front. The main consequence of this commit is that it's a bit more difficult for embeddings to know what the expected types of results are. No type information is provided when a host function is defined, not even function arity. This means that when the host function is invoked it may not know how many results are expected to be produced and of what type. Typically though a bindings generator is used somewhere along the way so that's expected to alleviate this issue. Finally my hope is to enhance this "dynamic" API in the future with a bit more information so the type information is more readily accessible at runtime. For now though hosts will have to "simply know what to do".
dicej
approved these changes
Mar 8, 2024
Co-authored-by: Joel Dice <joel.dice@fermyon.com>
github-actions
bot
added
fuzzing
Subscribe to Label Actioncc @fitzgen, @peterhuene
This issue or pull request has been labeled: "fuzzing", "wasmtime:api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This commit removes the
&Componentargument from thecomponent::Linker::func_newAPI. This is inspired by #8062 whereValholds less type information as well in addition to the realization that type-checking happens at runtime rather than instantiation time.This argument was originally added to mirror
wasmtime::Linker::func_newwhich takes a type argument of the core wasm function that's being defined. Unlike core wasm, though, component functions already have to carry along their type information as part of function calls to handle resources correctly. This means that when a host function is invoked the type is already known of all the parameters and results. Additionally values are already required to be type-checked going back into wasm, so there's less of a need to perform an additional type-check up front.The main consequence of this commit is that it's a bit more difficult for embeddings to know what the expected types of results are. No type information is provided when a host function is defined, not even function arity. This means that when the host function is invoked it may not know how many results are expected to be produced and of what type. Typically though a bindings generator is used somewhere along the way so that's expected to alleviate this issue.
Finally my hope is to enhance this "dynamic" API in the future with a bit more information so the type information is more readily accessible at runtime. For now though hosts will have to "simply know what to do".