WASI semver compatibility should apply to exports #8395
Labels
Comments
alexcrichton
added
wasi
|
Removing exports in a new interface version should be trivially fine? Adding non-optional exports shouldn't be allowed as the host may attempt to call them. Adding optional exports would be fine, but the component model doesn't have a way to represent them, right? |
|
Correct yeah, the problem here has to do with |
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Jun 12, 2024
This commit is a change to Wasmtime's public API for `wasmtime::component::Instance` that reorganizes how component exports are loaded. Previously there was a system where `Instance::exports()` was called that that was sort of "iterated over" in a builder-style pattern to acquire the actual export desired. This required lifetime trickery for nested instances and some unfortunate API bloat. The major downside of this approach is that it requires unconditional string lookups at runtime for exports and additionally does not serve as a great place to implement the semver-compatible logic of bytecodealliance#8395. The goal of this refactoring is to pave the way to improving this. The new APIs for loading exports now look a bit more similar to what's available for core modules. Notably there's a new `Component::export_index` method which enables performing a string lookup and returning an index. This index can in turn be passed to `Instance::get_*` to skip the string lookup when exports are loaded. The `Instance::exports` API is then entirely removed and dismantled. The only piece remaining is the ability to load nested exports which is done through an `Option` parameter to `Component::export_index`. The way to load a nested instance is now to first lookup the instance with `None` as this parameter an then the instance itself is `Some` to look up an export of that instance. This removes the need for a recursive-style lifetime-juggling API from wasmtime and in theory helps simplify the usage of loading exports.
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 18, 2024
* Un-nest exports in a component This commit flattens the representation of exports in a component to make them more easily indexable without forcing traversal through the hierarchy of instance imports/exports to get there. * Guarantee type information on component exports Don't have it optional in some cases and present in others, instead ensure there's type information for all component exports immediately available. * Refactor how component instance exports are loaded This commit is a change to Wasmtime's public API for `wasmtime::component::Instance` that reorganizes how component exports are loaded. Previously there was a system where `Instance::exports()` was called that that was sort of "iterated over" in a builder-style pattern to acquire the actual export desired. This required lifetime trickery for nested instances and some unfortunate API bloat. The major downside of this approach is that it requires unconditional string lookups at runtime for exports and additionally does not serve as a great place to implement the semver-compatible logic of #8395. The goal of this refactoring is to pave the way to improving this. The new APIs for loading exports now look a bit more similar to what's available for core modules. Notably there's a new `Component::export_index` method which enables performing a string lookup and returning an index. This index can in turn be passed to `Instance::get_*` to skip the string lookup when exports are loaded. The `Instance::exports` API is then entirely removed and dismantled. The only piece remaining is the ability to load nested exports which is done through an `Option` parameter to `Component::export_index`. The way to load a nested instance is now to first lookup the instance with `None` as this parameter an then the instance itself is `Some` to look up an export of that instance. This removes the need for a recursive-style lifetime-juggling API from wasmtime and in theory helps simplify the usage of loading exports. * Update `bindgen!` generated structures for exports This commit updates the output of `bindgen!` to have a different setup for exports of worlds to handle the changes from the previous commit. This introduces new `*Pre` structures which are generated alongside the existing `Guest` structures for example. The `*Pre` versions contain `ComponentExportIndex` from the previous commit and serve as a path to accelerating instantiation because all name lookups are skipped. * Update test expectations for `bindgen!`-generated output * Review comments * Fix doc link
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this issue
Jun 18, 2024
This commit is an implementation of component model semver compatibility for export lookups. Previously in bytecodealliance#7994 component imports were made semver-aware to ensure that bumping version numbers would not be a breaking change. This commit implements the same feature for component exports. This required some refactoring to move the definition of semver compat around and the previous refactoring in bytecodealliance#8786 enables frontloading this work to happen before instantiation. Closes bytecodealliance#8395
github-merge-queue bot
pushed a commit
that referenced
this issue
Jun 18, 2024
* Implement semver compatibility for exports This commit is an implementation of component model semver compatibility for export lookups. Previously in #7994 component imports were made semver-aware to ensure that bumping version numbers would not be a breaking change. This commit implements the same feature for component exports. This required some refactoring to move the definition of semver compat around and the previous refactoring in #8786 enables frontloading this work to happen before instantiation. Closes #8395 * Review comments * Fix tests
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #7994 the
component::Linkertype in Wasmtime was made aware of semver by enabling loading a component that requires 0.2.0 of an interface with a supplied 0.2.1 of an interface. This enables us to update WASI in Wasmtime without breaking the ability to load older components.This support, however, does not work for exports. If a component exports 0.2.0 and the runtime is generating bindings for 0.2.1 then loading the export will fail currently, there's no logic anywhere to probe for older verions.
This represents a snag in our story of WASI compatibility in Wasmtime and is something we should address before updating WASI to 0.2.1
The text was updated successfully, but these errors were encountered: