Changes in import.rs

301dc716 - Fix two security advisories. (#12652)

Tue, 24 Feb 2026 18:23:59 +0000

Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis introduces new knobs to Wasmtime to limit the scope of resourcesthat WASI implementations will allocate on behalf of guests. Unlikebackports to 41.0.x-and-prior these knobs all have default values whichare considered reasonable for hosts if they don't further tune them. Thefollowing CLI knobs have been added:* `-Smax-resources` - limits the total component-model resources a guest can allocate in a table* `-Shostcall-fuel` - a broad limit which enforces that at most this amount of data will be copied from the guest to the host in any one API call (e.g. `string` values can't be too big, `list` can't be quadratic, etc). This fuel is reset on each host function call.* `-Smax-random-size` - the maximal size of the return value of the `get-random-bytes` and `get-insecure-random-bytes` WASI functions.* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields` values to avoid infinitely buffering data within the host.The `http` crate has additionally been updated to avoid a panic whenadding too many headers to a `fields` object.Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice * CI fixes* Run rustfmt* Fix wasi-common build* Fix tests on 32-bit* Fix nightly test expectationsprtest:full---------Co-authored-by: Mark Bundschuh Co-authored-by: Pat Hickey Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

1e0b0b46 - Remove subtask reparenting (#12570)

Mon, 23 Feb 2026 21:00:21 +0000

Remove subtask reparenting (#12570)This commit updates the implementation of component-model-asyncprimitives to remove the manual subtask reparenting process. This isrequired to fix #12544 at a semantic level because a subtask isn't everactually reparented, even if its parent exits. The first part of thischange is to remove the `GuestTask::subtasks` field and all relevantmanipulations of it.This field, however, powered the `TaskExit` abstraction returned from`call_concurrent`. This commit then subsequently deletes `TaskExit` andall related infrastructure as it's no longer directly applicable as-is.The rest of this change is then updating tests/bindings/etc to accountfor these two changes.The main semantic changes related to tests are:* `wasmtime run`, with and without `--invoke`, no longer waits for all subtasks. This instead only waits for the main task returning before exiting. Whether or not this is the correct behavior is under discussion in WebAssembly/component-model#608* `wasmtime serve` has been updated to keep the store alive at least until the response body has been fully transmitted. This is also part of WebAssembly/component-model#608.* Some `component-async-tests`-related tests were updated to either avoid blocking the store as it wasn't needed or yield enough times to ensure that the test passes.Closes #12544prtest:full List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

8992b99b - trap on blocking call in sync task before return (#12043)

Tue, 09 Dec 2025 15:41:57 +0000

trap on blocking call in sync task before return (#12043)* trap on blocking call in sync task before returnThis implements a spec change (PR pending) such that tasks created for calls tosynchronous exports may not call potentially-blocking imports or return `wait`or `poll` callback codes prior to returning a value. Specifically, thefollowing are prohibited in that scenario:- returning callback-code.{wait,poll}- sync calling an async import- sync calling subtask.cancel- sync calling {stream,future}.{read,write}- sync calling {stream,future}.cancel-{read,write}- calling waitable-set.{wait,poll}- calling thread.suspendThis breaks a number of tests, which will be addressed in follow-up commits:- The `{tcp,udp}-socket.bind` implementation in `wasmtime-wasi` is implemented using `Linker::func_wrap_concurrent` and thus assumed to be async, whereas the WIT interface says they're sync, leading to a type mismatch error at runtime. Alex and I have discussed this and have a general plan to address it.- A number of tests in the tests/component-model submodule that points to the spec repo are failing. Those will presumably be fixed as part of the upcoming spec PR (although some could be due to bugs in this implementation, in which case I'll fix them).- A number of tests in tests/misc_testsuite are failing. I'll address those in a follow-up commit.Signed-off-by: Joel Dice * call `check_may_leave` before `check_blocking``check_blocking` needs access to the current task, but that's not set forpost-return functions since those should not be calling _any_ imports at all, sofirst check for that.Signed-off-by: Joel Dice * fix `misc_testsuite` test regressionsThis amounts to adding `async` to any exported component functions that mightneed to block.Signed-off-by: Joel Dice * simplify code in `ConcurrentState::check_blocking`Signed-off-by: Joel Dice * make `thread.yield` a no-op in non-blocking contextsPer the proposed spec changes, `thread.yield` should return control to the guestimmediately without allowing any other thread to run. Similarly, when anasync-lifted export or callback returns `CALLBACK_CODE_YIELD`, we should callthe callback again immediately without allowing another thread to run.Signed-off-by: Joel Dice * fix build when `component-model-async` feature disabledSigned-off-by: Joel Dice * fix more test regressionsSigned-off-by: Joel Dice * fix more test regressionsNote that this temporarily updates the `tests/component-model` submodule to thebranch for https://github.com/WebAssembly/component-model/pull/577 until that PRis merged.Signed-off-by: Joel Dice * tweak `Trap::CannotBlockSyncTask` messageThis clarifies that such a task cannot block prior to returning.Signed-off-by: Joel Dice * fix cancel_host_future testSigned-off-by: Joel Dice * trap sync-lowered, guest->guest async calls in sync tasksI somehow forgot to address this earlier. Thanks to Luke for catching this.Note that this commit doesn't include test coverage, but Luke's forthecomingtests in the `component-model` repo will cover it, and we'll pull that in withthe next submodule update.Signed-off-by: Joel Dice * switch back to `main` branch of `component-model` repo...and skip or `should_fail` the tests that won't pass untilhttps://github.com/WebAssembly/component-model/pull/578 is merged.Signed-off-by: Joel Dice * add `trap-if-block-and-sync.wast`We'll remove this again in favor of the upstream version oncehttps://github.com/WebAssembly/component-model/pull/578 has been merged.Signed-off-by: Joel Dice * address review feedback- Assert that `StoreOpaque::suspend` is not called in a non-blocking context except in specific circumstances- Typecheck async-ness for dynamic host functions- Use type parameter instead of value parameter in `call_host[_dynamic]`Signed-off-by: Joel Dice * add explanation comments to `check_blocking` callsSigned-off-by: Joel Dice * fix fuzz test oracle for async functionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

87d1730b - Supply type information in `func_new` for components (#11944)

Mon, 27 Oct 2025 21:25:15 +0000

Supply type information in `func_new` for components (#11944)Originally the `Linker::func_new` type for components was modeled aftercore wasm where a type was provided when the type was defined. This wasdifficult, however, because there's no way to construct types right nowand instead a component had to be created and compiled to acquire typeinformation from it. Later various refactorings meant that it waspossible to drop the type information entirely from `func_new` meaningthat it was "typeless" in a sense, and the functionality relied on thetagged nature of `Val` which always knows its type.This has proven a bit difficult to integrate into Python in some workI've been doing. Namely in Python component values are (at least IMO)best represented as native Python values where possible. Native Pythondoesn't distinguish, however, between integer bit widths (orsignededness). This means that converting a Python value to a componentvalue requires type information to guide the conversion process.Currently when defining a function in a linker there's no way to get atthis type information meaning that the types would need to be suppliedin Python, bringing up the same shortcomings of not being able to createtypes.In lieu of filling out type constructors, which is itself quitenontrivial, I've opted to do the next-most-easiest thing which is tosupply the type to the callee when an import is invoked. This means thatthe callee has all the type information necessary. While this issomewhat costly in that it clones a few arcs it's expected to be a dropin the bucket compared to the inefficiencies of `Val` so it's at leastin the same spirit of the cost of the API right now.My intention is to use this to update the C API for components andeventually end up with type information when Python is invoked inwasmtime-py. Also while I'm using wasmtime-py as a motivating case herethat's sort of just one example of a host embedding which doesn't havethe full fidelity of Rust's type system and might benefit from this. List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

7e39c25e - move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

Mon, 06 Oct 2025 19:53:10 +0000

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)* move `ConcurrentState` from `ComponentInstance` to `Store`This has a few benefits:- No need to specify an instance when creating or piping from a stream or future.- No need to track the instance in an `Accessor`.- You may now execute tasks for multiple instances in a single event loop.The main drawback is that, if one of several instances within a single storetraps, it effectively means all instances have trapped, and the store can't beused to create new instances. The way to avoid that is to use separate storesfor instances which must be isolated from others.As a result of this change, a lot of code had to move from e.g. `impl Instance`to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changesthemselves are almost entirely non-functional.Fixes #11226Signed-off-by: Joel Dice * fix non-component-model-async buildSigned-off-by: Joel Dice * fix outdated doc commentSigned-off-by: Joel Dice * address review feedback- restore `ComponentStoreData` encapsulation- avoid conditional code duplication in `LiftContext::new`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

f75ae788 - return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)

Wed, 10 Sep 2025 16:37:25 +0000

return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)* return `TaskExit` future from `[Typed]Func::call_concurrent`In addition to returning the value produced by the callee, these functions nowalso return a `TaskExit` future which resolves once the subtask (and anytransitively-created subtasks) have exited. This partially addresses #11600;the next step will be to add a `wasmtime-wit-bindgen` option to expose the`TaskExit` value in generated bindings.Signed-off-by: Joel Dice * address review feedback`TaskExit` now has an `async fn block` instead of closing over an `implAsAccessor` and implementing `Future`.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

2200d82c - Change signature of `Func::call_concurrent` (#11266)

Thu, 17 Jul 2025 19:29:49 +0000

Change signature of `Func::call_concurrent` (#11266)Update it to use slices in a similar manner to `Func::call_async`.Closes #11218 List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

da265515 - Rename `Instance::run_with` to `Instance::run_concurrent` (#11259)

Wed, 16 Jul 2025 21:47:20 +0000

Rename `Instance::run_with` to `Instance::run_concurrent` (#11259)* Rename `Instance::run_with` to `Instance::run_concurrent`This commit renames `run_with` to `run_concurrent` and additionallydeletes the `Instance::run` method. With `Accessor`-related changesthere's no need to have a "just run with a future" method as almosteverything is going to require `run_concurrent` anyway to acquire anaccessor.Closes #11224* Fix compile issues* Update crates/wasmtime/src/runtime/component/func/typed.rsCo-authored-by: Joel Dice ---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

64bc3bd9 - Start to use `&Accessor` more in concurrent code (#11238)

Tue, 15 Jul 2025 15:14:02 +0000

Start to use `&Accessor` more in concurrent code (#11238)* Start to use `&Accessor` more in concurrent codeAfter discussion with Joel we've concluded that while `&mut Accessor`was originally added to model host functions it is also appropriate touse it to model embedder-rooted invocations of items such as wasm aswell. Effectively the conclusion we reached was that`*::call_concurrent` should be taking `&Accessor`, not`StoreContextMut`. This has a number of benefits to it over the previousiteration:* This makes exports behave more like imports where `Accessor` means "you're in the concurrent world".* This makes exports have an `async fn` signature which is easier to read and understand.* This automatically enforces the guarantee that the returned future is only polled within the main event loop because the future is always considered to close over the `&Accessor` provided meaning it statically cannot live outside of the event loop.* This paves the way forward to future refactorings to avoid storing so much state within a `Store` and instead try to store state directly in futures themselves. This should make cancellation more natural and eventually also remove `'static` bounds on params/results. Furthermore this should make it easier to avoid spawning tasks internally by storing state in futures instead of spawned tasks.In doing this one of the main questions we were faced with was what todo about `&mut Accessor`, namely the `mut` part. With a mutableaccessor it would be only possible to call one function concurrently.One option considered was to add combinators like `Accessor::join` and`Accessor::race` but in the end we decided to avoid going that directionand instead switch to `&Accessor` everywhere, freely enablingaliasing of the accessor. This has the downside that `Accessor::with` isnow a relatively dangerous function in that it can panic, but idiomaticusage of it is not expected to panic as the distinction between the`async` and sync boundary of `Accessor` vs `StoreContextMut` is expectedto naturally make the recursive panic condition of `with` rare to comeup in practice.Concrete changes in this commit are:* `Accessor::with` now requires `&self`.* `Accessor::spawn` now requires `&self`.* Host functions are now given `&Accessor`, not `&mut Accessor`.* `{Typed,}Func::call_concurrent` is now an `async fn` which takes an `&Accessor` instead of `StoreContextMut`.* Guest bindings generation for concurrent invocations now looks exactly like async bindings generation except for replacing `StoreContextMut` with `Accessor`.Note that this commit does not yet update the internal implementationsof these functions to benefit from the new abilities that taking`&Accessor` implies. Instead that's deferred to a future update asnecessary. Instead this is only updating the public API of the`wasmtime` crate to enable these refactorings in the future.Also note that this does not yet update all functions to take`&Accessor`. Notably futures and streams still need to be updated.cc #11224* Review comments---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

804060c8 - add Component Model async ABI tests (#11136)

Fri, 11 Jul 2025 23:32:19 +0000

add Component Model async ABI tests (#11136)* add Component Model async ABI testsThis pulls in the tests from the `wasip3-prototyping` repo, minus the onesrequiring WASIp3 support in `wasmtime-wasi[-http]`, which will be PR'dseparately.* add audits and exemptions for new `component-async-tests` depsIn order to convince `cargo vet` that we only needed these deps to be`safe-to-run` (not necessarily `safe-to-deploy`, since it's test code), I'vemoved the `wasm-compose` dep to the `dev-dependencies` section of the`Cargo.toml` file, which required rearranging some code.I've exempted `wasm-compose` since it's a BA project, and also exempted all butone of the remaining new deps since they each get well over 10,000 downloads perday from crates.io. I've audited and certified the remaining dep, `im-rc`,which came in a bit shy of the 10,000-per-day mark.Signed-off-by: Joel Dice * simplify `component_async_tests::util::sleep`Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

95cc0297 - Component and Instance have corresponding get_export, get_export_index (#10597)

Wed, 16 Apr 2025 21:38:26 +0000

Component and Instance have corresponding get_export, get_export_index (#10597)* component::Instance: get_export gives a ComponentItem, ExportIndex pairjust like Component::export_index does* align Instance and Component with get_export and get_export_index* fix example* component macro expanded: bless output* fix component model tests* cli only needs get_export_index* code review: deduplicate export to typedef transformation into ComponentItem::from_export List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

46098121 - style: simplify string formatting (#9047)

Wed, 31 Jul 2024 14:45:20 +0000

style: simplify string formatting (#9047)* style: simplify string formatting* fix: formatting in `benches/call.rs` List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

3171ef6d - Redesign how component exports work (#8786)

Tue, 18 Jun 2024 01:05:39 +0000

Redesign how component exports work (#8786)* Un-nest exports in a componentThis commit flattens the representation of exports in a component tomake them more easily indexable without forcing traversal through thehierarchy of instance imports/exports to get there.* Guarantee type information on component exportsDon't have it optional in some cases and present in others, insteadensure there's type information for all component exports immediatelyavailable.* Refactor how component instance exports are loadedThis commit is a change to Wasmtime's public API for`wasmtime::component::Instance` that reorganizes how component exportsare loaded. Previously there was a system where `Instance::exports()`was called that that was sort of "iterated over" in a builder-stylepattern to acquire the actual export desired. This required lifetimetrickery for nested instances and some unfortunate API bloat. The majordownside of this approach is that it requires unconditional stringlookups at runtime for exports and additionally does not serve as agreat place to implement the semver-compatible logic of #8395. The goalof this refactoring is to pave the way to improving this.The new APIs for loading exports now look a bit more similar to what'savailable for core modules. Notably there's a new`Component::export_index` method which enables performing a stringlookup 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 isdone through an `Option` parameter to `Component::export_index`. Theway 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 lookup an export of that instance. This removes the need for arecursive-style lifetime-juggling API from wasmtime and in theory helpssimplify the usage of loading exports.* Update `bindgen!` generated structures for exportsThis commit updates the output of `bindgen!` to have a different setupfor exports of worlds to handle the changes from the previous commit.This introduces new `*Pre` structures which are generated alongside theexisting `Guest` structures for example. The `*Pre` versions contain`ComponentExportIndex` from the previous commit and serve as a path toaccelerating instantiation because all name lookups are skipped.* Update test expectations for `bindgen!`-generated output* Review comments* Fix doc link List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

6a710b92 - Remove type information from dynamic component funcs (#8070)

Fri, 08 Mar 2024 22:45:56 +0000

Remove type information from dynamic component funcs (#8070)* Remove type information from dynamic component funcsThis commit removes the `&Component` argument from the`component::Linker::func_new` API. This is inspired by #8062 where `Val`holds less type information as well in addition to the realization thattype-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 corewasm function that's being defined. Unlike core wasm, though, componentfunctions already have to carry along their type information as part offunction calls to handle resources correctly. This means that when ahost function is invoked the type is already known of all the parametersand results. Additionally values are already required to be type-checkedgoing back into wasm, so there's less of a need to perform an additionaltype-check up front.The main consequence of this commit is that it's a bit more difficultfor embeddings to know what the expected types of results are. No typeinformation is provided when a host function is defined, not evenfunction arity. This means that when the host function is invoked it maynot know how many results are expected to be produced and of what type.Typically though a bindings generator is used somewhere along the way sothat's expected to alleviate this issue.Finally my hope is to enhance this "dynamic" API in the future with abit more information so the type information is more readily accessibleat runtime. For now though hosts will have to "simply know what to do".* Update crates/wasmtime/src/runtime/component/linker.rsCo-authored-by: Joel Dice * Fix doc links* Fix component call benchmarks---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

9de6828e - Remove type information from `wasmtime::component::Val` (#8062)

Fri, 08 Mar 2024 15:33:36 +0000

Remove type information from `wasmtime::component::Val` (#8062)This commit is a large refactor of the `Val` type as used withcomponents to remove inherent type information present currently. The`Val` type is now only an AST of what a component model value looks likeand cannot fully describe the type that it is without further context.For example enums only store the case that's being used, not the fullset of cases.The motivation for this commit is to make it simpler to use andconstruct `Val`, especially in the face of resources. Some problemssolved 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 `Val` shape without extra types.* Functionally when working with `Val` there's now only one typecheck instead of two. Previously a typecheck was performed first when a `Val` was 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 `Val` as-is is a pretty inefficientrepresentation of component model values, for example flags are storedas a list of strings. While semantically correct this is quiteinefficient for most purposes other than "get something working". Tothat extent my goal is to, in the future, add traits that enablebuilding a custom user-defined `Val` (of sorts), but still dynamically.This should enable embedders to opt-in to a more efficientrepresentation that relies on contextual knowledge. List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

6a7ef27b - Make `wasmtime::WasmCoreDump` serializable (#7078)

Mon, 25 Sep 2023 20:11:45 +0000

Make `wasmtime::WasmCoreDump` serializable (#7078)This commit makes it so that the library type for core dumps is serializableinto the standard binary format for core dumps.Additionally, this commit makes it so that we use the library type forgenerating core dumps in the CLI. We previously were using a one-offimplementation of core dump generation that only had backtrace information andno instances, modules, globals, or memories included. The library type has allthat information, so the core dumps produced by our CLI will both be morefeatureful and be generated by shared code paths going forward.Along the way, implementing all this required some new helper methods sprinkledthroughout `wasmtime` and `wasmtime-runtime`:* `wasmtime::Instance::module`: get the module that a `wasmtime::Instance` is an instance of. This is public, since it seems generally useful. This involved adding a new return value from `ModuleRegistry::register_module` that is an identifier that can be used to recover a reference to the registered module.* `wasmtime::Instance::all_{globals,memories}`: get the full global/memory index space. I made these `pub(crate)` out of caution. I don't think we want to commit to exposing non-exported things in the public API, even if we internally need them for debugging-related features like core dumps. These also needed corresponding methods inside `wasmtime-runtime`.* `wasmtime::{Global,Memory}::hash_key`: this was needed to work around the fact that each time you call `{Global,Memory}::from_wasmtime`, it creates a new entry in the `StoreData` and so you can get duplicates. But we need to key some hash maps on globals and memories when constructing core dumps, so we can't treat the underlying `Stored` as a hash key because it isn't stable across duplicate `StoreData` entries. So we have these new methods. They are only `pub(crate)`, are definitely implementation details, and aren't exposed in the public API.* `wasmtime::FrameInfo::module`: Each frame in a backtrace now keeps a handle to its associated module instead of just the name. This is publicly exposed because it seems generally useful. This means I also deprecated `wasmtime::FrameInfo::module_name` since you can now instead do `frame.module().name()` to get that exact same info. I updated callers inside the repo. List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs

e69a7f73 - Do proper type checking for type handles. (#7065)

Thu, 21 Sep 2023 17:55:43 +0000

Do proper type checking for type handles. (#7065)Instead of relying purely on the assumption that type handles can be comparedcheaply by pointer equality, fallback to a more expensive walk of thetype tree that recursively compares types structurally.This allows different components to call into each other as long astheir types are structurally equivalent.Signed-off-by: Ryan Levick List of files: /wasmtime-44.0.1/tests/all/component_model/import.rs