Changes in bindgen.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/bindgen.rs

fb1827ee - `wit-bindgen`: Add an option to use `anyhow::Result` instead of `wasmtime::Result` (#12331)

Tue, 13 Jan 2026 18:46:48 +0000

`wit-bindgen`: Add an option to use `anyhow::Result` instead of `wasmtime::Result` (#12331)* wit-bindgen: Add an option to use `anyhow::Result` instead of `wasmtime::Result`* Add option to reference docs* Rename `anyhow` dev dependency to `anyhow-for-testing` List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.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/bindgen.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/bindgen.rs

020727d0 - Update wasm-tools dependencies (#12031)

Fri, 14 Nov 2025 21:34:45 +0000

Update wasm-tools dependencies (#12031)* Change separator style* Update wasm-tools dependencies* Also update wit-bindgen* Drop `[async]` name prefixes* Plumb `async` as part of a function typeRuntime handling of async functions and new traps are to be implementedin subsequent commits. This is just getting everything running again.* Run clang-format, also add test* Fix some more wast tests---------Co-authored-by: Sy Brand List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.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/bindgen.rs

1155d6df - Redesign function configuration in `bindgen!` (#11328)

Mon, 28 Jul 2025 18:31:06 +0000

Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime's `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async, only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly opt-in to component model async signatures and applied to all imports/exports.* The `trappable_imports` configuration would indicate a list of imports allowed to trap and it had special configuration for everything, nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so: bindgen!({ // ... imports: { // enable tracing for just this function "my:local/interface/func": tracing, // enable verbose tracing for just this function "my:local/interface/other-func": tracing | verbose_tracing, // this is blocking in WIT, but generate async bindings for // it "my:local/interface/[method]io.block": async, // like above, but use "concurrent" bindings which have // access to the store. "my:local/interface/[method]io.block-again": async | store, // everything else is, by default, trappable default: trappable, }, });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be generated. This is either `CallStyle::Async` or `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to the store on the host. This is only implemented right now for `async | store` functions which map to `CallStyle::Concurrent`. In the future I'd like to support just-`store` functions which means that you could define a synchronous function with access to the store in addition to an asynchronous function.* `trappable` - this means that the function returns a `wasmtime::Result`. If `trappable_errors` is applicable then it means just a `Result` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map depending on if the function is imported or exported. If there is no matching rule then use the `default` rule if present. This is the initial set of flags for the function (or empty if nothing was found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it's controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there's only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it's up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.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/bindgen.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/bindgen.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/bindgen.rs

c71d3aab - Deps: Update `wasm-tools` crates to 0.233.0 (#10915)

Wed, 04 Jun 2025 18:53:37 +0000

Deps: Update `wasm-tools` crates to 0.233.0 (#10915)* Update `wasm-tools` deps to 0.233.0* Update `cargo vet` metadataJust a prune and wildcard renewals* cargo fmt* Fix type export identifiers* Fix more type identifiers in exports in WAT List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

f6775a33 - Replace `GetHost` with a function pointer, add `HasData` (#10770)

Tue, 13 May 2025 05:47:01 +0000

Replace `GetHost` with a function pointer, add `HasData` (#10770)* Replace `GetHost` with a function pointer, add `HasData`This commit is a refactoring to the fundamentals of the `bindgen!` macroand the functions that it generates. Prior to this change thefundamental entrypoint generated by `bindgen!` was a function`add_to_linker_get_host` which takes a value of type `G: GetHost`. This`GetHost` implementation is effectively an alias for a closure whosereturn value is able to close over the parameter given lfietime-wise.The `GetHost` abstraction was added to Wasmtime originally to enableusing any type that implements `Host` traits, not just `&mut U` as wasoriginally supported. The definition of `GetHost` was _just_ right toenable a type such as `MyThing<&mut T>` to implement `Host` and aclosure could be provided that could return it. At the time that`GetHost` was added it was known to be problematic from anunderstandability point of view, namely:* It has a non-obvious definition.* It's pretty advanced Rust voodoo to understand what it's actually doing* Using `GetHost` required lots of `for<'a> ...` in places which is unfamiliar syntax for many.* `GetHost` values couldn't be type-erased (e.g. put in a trait object) as we couldn't figure out the lifetime syntax to do so.Despite these issues it was the only known solution at hand so we landedit and kept the previous `add_to_linker` style (`&mut T -> &mut U`) as aconvenience. While this has worked reasonable well (most folks just tryto not look at `GetHost`) it has reached a breaking point in the WASIp3work.In the WASIp3 work it's effectively now going to be required that the`G: GetHost` value is packaged up and actually stored inside ofaccessors provided to host functions. This means that `GetHost` valuesnow need to not only be taken in `add_to_linker` but additionallyprovided to the rest of the system through an "accessor". This was madepossible in #10746 by moving the `GetHost` type into Wasmtime itself (asopposed to generated code where it lived prior).While this worked with WASIp3 and it was possible to plumb `G: GetHost`safely around, this ended up surfacing more issues. Namely all"concurrent" host functions started getting significantly morecomplicated `where` clauses and type signatures. At the end of the day Ifelt that we had reached the end of the road to `GetHost` and wanted tosearch for alternatives, hence this change.The fundamental purpose of `GetHost` was to be able to express, in ageneric fashion:* Give me a closure that takes `&mut T` and returns `D`.* The `D` type can close over the lifetime in `&mut T`.* The `D` type must implement `bindgen!`-generated traits.A realization I had was that we could model this with a genericassociated type in Rust. Rust support for generic associated types isrelatively new and not something I've used much before, but it ended upbeing a perfect model for this. The definition of the new `HasData`trait is deceptively simple: trait HasData { type Data<'a>; }What this enables us to do though is to generate `add_to_linker`functions that look like this: fn add_to_linker( linker: &mut Linker, getter: fn(&mut T) -> D::Data<'_>, ) -> Result<()> where D: HasData, for<'a> D::Data<'a>: Host;This definition here models `G: GetHost` as a literal function pointer,and the ability to close over the `&mut T` lifetime with type (not just`&mut U`) is expressed through the type constructor `type Data<'a>`).Ideally we could take a generic generic associated type (I'm not evensure what to call that), but that's not something Rust has today.Overall this felt like a much simpler way of modeling `GetHost` and itsrequirements. This plumbed well throughout the WASIp3 work and thesignatures for concurrent functions felt much more appropriate in termsof complexity after this change. Taking this change to the limit meansthat `GetHost` in its entirety could be purged since all usages of itcould be replaced with `fn(&mut T) -> D::Data<'a>`, a hopefully muchmore understandable type.This change is not all rainbows however, there are some gotchas thatremain:* One is that all `add_to_linker` generated functions have a `D: HasData` type parameter. This type parameter cannot be inferred and must always be explicitly specified, and it's not easy to know what to supply here without reading documentation. Actually supplying the type parameter is quite easy once you know what to do (and what to fill in), but it may involve defining a small struct with a custom `HasData` implementation which can be non-obvious.* Another is that the `G: GetHost` value was previously a full Rust closure, but now it's transitioning to a function pointer. This is done in preparation for WASIp3 work where the function needs to be passed around, and doing that behind a generic parameter is more effort than it's worth. This means that embedders relying on the true closure-like nature here will have to update to using a function pointer instead.* The function pointer is stored in locations that require `'static`, and while `fn(T)` might be expected to be `'static` regardless of `T` is is, in fact, not. This means that practically `add_to_linker` requires `T: 'static`. Relative to just before this change this is a possible regression in functionality, but there orthogonal reasons beyond just this that we want to start requiring `T: 'static` anyway. That means that this isn't actually a regression relative to #10760, a related change.The first point is partially ameliorated with WASIp3 work insofar thatthe `D` type parameter will start serving as a location to specify whereconcurrent implementations are found. These concurrent methods don'ttake `&mut self` but instead are implemented for `T: HasData` types. Inthat sense it's more justified to have this weird type parameter, but inthe meantime without this support it'll feel a bit odd to have thislittle type parameter hanging off the side.This change has been integrated into the WASIp3 prototyping repositorywith success. This has additionally been integrated into the Spinembedding which has one of the more complicated reliances on`*_get_host` functions known. Given that it's expected that while thisis not necessarily a trivial change to rebase over it should at least bepossible.Finally the `HasData` trait here has been included with what I'm hopingis a sufficient amount of documentation to at least give folks a springboard to understand it. If folks have confusion about this `D` typeparameter my hope is they'll make their way to `HasData` which showcasesvarious patterns for "librarifying" host implementations of WITinterfaces. These patterns are all used throughout Wasmtime and WASIcurrently in crates and tests and such.* Update expanded test expectations List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

97f1b1d8 - Remove extraneous `Send` bound from bindgen-generated exports (#10685)

Mon, 28 Apr 2025 16:58:23 +0000

Remove extraneous `Send` bound from bindgen-generated exports (#10685)Accidental regression from #10044.Closes #10677 List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

7a66c39a - Remove some `#![expect(clippy::allow_attributes_without_reason)]` (#10661)

Wed, 23 Apr 2025 21:07:33 +0000

Remove some `#![expect(clippy::allow_attributes_without_reason)]` (#10661)Clean up some crates by migrating from `#[allow]` to `#[expect]`(ideally) or `#[allow]`-with-reason List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

d0a55990 - Remove async-trait in bindgen (#9867)

Fri, 20 Dec 2024 16:39:06 +0000

Remove async-trait in bindgen (#9867)* use trait_variant and async-func-in-trait instead of async-trait* remove all async_trait::async_trait related to bindgen! proc_macro* remove pub use async_trait::async_trait in __internal* bless `component-macro` tests to reflect `async_trait` removalSigned-off-by: Joel Dice * add `trait-variant` exemption to supply-chain/config.tomlThis exempts the `trait-variant` crate from vetting since it is published andmaintained by the rust-lang organization and is officially recommended by theRust project.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

c230353d - Configure WIT feature gates at runtime & implement wasi-cli `exit-with-code` (#9381)

Mon, 07 Oct 2024 20:27:14 +0000

Configure WIT feature gates at runtime & implement wasi-cli `exit-with-code` (#9381)* Remove `features` configuration from component::bindgen! and always emit all unstable members. These features will be gated at runtime.* Implement wasi-cli's unstable `exit-with-code`* Add codegen test for unstable features* Add LinkOptions type and add a parameter to all add_to_linker functions in for worlds/interfaces that use any unstable feature.* More descriptive test feature names.* Generate feature gate `if` checks* Expose `cli-exit-with-code` as CLI option* Generate bespoke option types per interface and world.* Add unit test* Remove exit code restriction on Windows* Add cli_exit_with_code test* Use BTreeSet to generate the options in consistent order* Change wasmtime-wasi's `add_to_linker_(a)sync` signature back to how it was and add new variants that take the option parameters.* Lift Windows exit code restriction in tests* Lift Windows exit code restriction List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.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/bindgen.rs

3cd96e17 - Add `GetHost` to generated bindings for more flexible linking (#8448)

Mon, 13 May 2024 18:07:02 +0000

Add `GetHost` to generated bindings for more flexible linking (#8448)* Remove unused generated `add_root_to_linker` method* WIP: bindgen GetHost* Compile with Rust 1.78+Use as a guide of how to implement this by making the `GetHost` trait a bituglier.* Add an option to skip `&mut T -> T` implsAlso enable this for WASI crates since they do their own thing with`WasiView` for now. A future refactoring should be able to remove thisoption entirely and switch wasi crates to a new design of `WasiView`.* Update test expectations* Review comments* Undo temporary change* Handle some TODOs* Remove no-longer-relevant note* Fix wasmtime-wasi-http doc link---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/tests/all/component_model/bindgen.rs