Remove the need to have a Store for an InstancePre
#5683
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 relaxes a requirement of the `InstancePre` API, notably its construction via `Linker::instantiate_pre`. Previously this function required a `Store<T>` to be present to be able to perform type-checking on the contents of the linker, and now this requirement has been removed. Items stored within a linker are either a `HostFunc`, which has type information inside of it, or an `Extern`, which doesn't have type information inside of it. Due to the usage of `Extern` this is why a `Store` was required during the `InstancePre` construction process, it's used to extract the type of an `Extern`. This commit implements a solution where the type information of an `Extern` is stored alongside the `Extern` itself, meaning that the `InstancePre` construction process no longer requires a `Store<T>`. One caveat of this implementation is that some items, such as tables and memories, technically have a "dynamic type" where during type checking their current size is consulted to match against the minimum size required of an import. This no longer works when using `Linker::instantiate_pre` as the current size used is the one when it was inserted into the linker rather than the one available at instantiation time. It's hoped, however, that this is a relatively esoteric use case that doesn't impact many real-world users. Additionally note that this is an API-breaking change. Not only is the `Store` argument removed from `Linker::instantiate_pre`, but some other methods such as `Linker::define` grew a `Store` argument as the type needs to be extracted when an item is inserted into a linker. Closes bytecodealliance#5675
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 |
Subscribe to Label Actioncc @peterhuene
This issue or pull request has been labeled: "wasmtime:c-api"
Thus the following users have been cc'd because of the following labels:
To subscribe or unsubscribe from this label, edit the |
abrown
reviewed
Feb 1, 2023
Co-authored-by: Andrew Brown <andrew.brown@intel.com>
pchickey
approved these changes
Feb 2, 2023
jbourassa
added a commit
to bytecodealliance/wasmtime-rb
that referenced
this pull request
Feb 24, 2023
This includes a breaking change, following bytecodealliance/wasmtime#5683. `Wasmtime::Linker#define` now takes a store as a first argument.
jbourassa
added a commit
to bytecodealliance/wasmtime-rb
that referenced
this pull request
Feb 24, 2023
This includes a breaking change, following bytecodealliance/wasmtime#5683. `Wasmtime::Linker#define` now takes a store as a first argument.
lann
added a commit
to lann/wasmtime
that referenced
this pull request
Mar 17, 2023
The `store` param was removed in bytecodealliance#5683
alexcrichton
pushed a commit
that referenced
this pull request
Mar 17, 2023
The `store` param was removed in #5683
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 relaxes a requirement of the
InstancePreAPI, notably its construction viaLinker::instantiate_pre. Previously this function required aStore<T>to be present to be able to perform type-checking on the contents of the linker, and now this requirement has been removed.Items stored within a linker are either a
HostFunc, which has type information inside of it, or anExtern, which doesn't have type information inside of it. Due to the usage ofExternthis is why aStorewas required during theInstancePreconstruction process, it's used to extract the type of anExtern. This commit implements a solution where the type information of anExternis stored alongside theExternitself, meaning that theInstancePreconstruction process no longer requires aStore<T>.One caveat of this implementation is that some items, such as tables and memories, technically have a "dynamic type" where during type checking their current size is consulted to match against the minimum size required of an import. This no longer works when using
Linker::instantiate_preas the current size used is the one when it was inserted into the linker rather than the one available at instantiation time. It's hoped, however, that this is a relatively esoteric use case that doesn't impact many real-world users.Additionally note that this is an API-breaking change. Not only is the
Storeargument removed fromLinker::instantiate_pre, but some other methods such asLinker::definegrew aStoreargument as the type needs to be extracted when an item is inserted into a linker.Closes #5675