Changes in empty_async.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.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/crates/component-macro/tests/expanded/empty_async.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.rs

bb77f602 - wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)

Mon, 21 Apr 2025 21:54:01 +0000

wasmtime-wit-bindgen: Typecheck exports at {Foo}Indices construction (#10610)* wasmtime::component: make it possible to typecheck export funcs* wasmtime-wit-bindgen: add typechecking on construction of Indices struct* wit-bindgen: reduce to a single Indices constructor which takes InstancePre* bless bindgen output List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.rs

99d861cb - Expand the set of constructors of `bindgen!`-generated bindings (#9177)

Wed, 28 Aug 2024 16:36:26 +0000

Expand the set of constructors of `bindgen!`-generated bindings (#9177)* Expand the set of constructors of `bindgen!`-generated bindingsThis commit expands the set of supported constructors for `bindgen!`generated structures with the goal of bringing back`World::new(&mut store, instance)`. This method was removed previouslyin a refactoring to add `*Pre` structures but refactoring preexistingcode to use `*Pre` isn't always easy, so these extra generated bindingsprovide a smoother migration path for code from before.* Update test expectations List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.rs

5393c2bf - Reduce typo count (#8951)

Mon, 15 Jul 2024 14:26:59 +0000

Reduce typo count (#8951) List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.rs

f471b4dc - Refactor and document the wasmtime-wasi-http more (#8861)

Mon, 24 Jun 2024 15:24:58 +0000

Refactor and document the wasmtime-wasi-http more (#8861)* Improve some documentation of the `wasmtime-wasi` crateShow a few examples of using `with` to point to upstream `wasmtime-wasi`for bindings.* Refactor and document the `wasmtime-wasi-http` moreThis commit primarily adds a complete example of using`wasmtime-wasi-http` to the documentation. Along the way I've done anumber of other refactorings too:* `bindgen!`-generated `*Pre` structures now implement `Clone`.* `bindgen!`-generated `*Pre` structures now have an `engine` method.* `bindgen!`-generated `*Pre` structures now have an `instance_pre` method.* The structure of `wasmtime-wasi-http` now matches `wasmtime-wasi`, notably: * The `proxy` module is removed * `wasmtime_wasi_http::add_to_linker_{a,}sync` is the top level add-to-linker function. * The `bindings` module now contains `Proxy` and `ProxyPre` along with a `sync` submodule. * The `bindings` module contains all bindings for `wasi:http` things.* The `add_only_*` methods are un-hidden and documented.* Code processing `req` has been simplified by avoiding decomposing-and-reconstructing a request.* The `new_incoming_request` method is now generic to avoid callers having to do boxing/mapping themselves.* Update expanded macro expectations* Remove unused import List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.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/crates/component-macro/tests/expanded/empty_async.rs

eea68f59 - bindgen: Commit expanded bindgen output for tests (#8558)

Tue, 07 May 2024 00:58:19 +0000

bindgen: Commit expanded bindgen output for tests (#8558)These outputs are checked in and verified to be fresh by a test so thatthey can be relied on for code review. List of files: /wasmtime-44.0.1/crates/component-macro/tests/expanded/empty_async.rs