Changes in wasi.rs

0ed11711 - Bump MSRV to 1.92.0. (#12828)

Tue, 24 Mar 2026 17:57:02 +0000

Bump MSRV to 1.92.0. (#12828)* Bump MSRV to 1.92.0.This is slightly overdue as 1.94.0 was released on 2026-03-05; thisbrings us back up to date with our N-2 policy.prtest:full* min-platform example: add wasi:cli/terminal-* interface stubsBumping MSRV to 1.92 pushes the build of the guest in the min-platformexample to use 1.94 (it explicitly builds with MSRV+2). Rust 1.94 hasnew bits in its WASI platform layer that require`terminal-{input,output,stdin,stdout,stderr` interfaces. This breaks themin-platform build.This commit updates the min-platform host ot have stub implementationsthat report no terminal present. List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.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/examples/min-platform/embedding/src/wasi.rs

41b081c1 - Migrate the min-platform example to `wasmtime::error` (#12267)

Wed, 07 Jan 2026 22:20:13 +0000

Migrate the min-platform example to `wasmtime::error` (#12267) List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs

c7dc2d52 - Disallow loading code on `x86_64-unknown-none` (#11553)

Thu, 28 Aug 2025 19:13:26 +0000

Disallow loading code on `x86_64-unknown-none` (#11553)* Disallow loading code on `x86_64-unknown-none`... And then also add an escape hatch to allow loading code. This commitis the culmination of discussion on #11506 with a proposed resolutionfor Wasmtime. The resolution being:* Wasmtime will reject loading code on `x86_64-unknown-none` platforms by default.* A new `Config::x86_float_abi_ok` escape hatch is added to bypass this check.* Documentation/errors are updated around `x86_float_abi_ok` to document the situation.* The `min-platform` example is updated to showcase how this is valid to run in that particular embedding (aka enable more features and sufficiently detect said features).The basic tl;dr; is that we can't detect in stable Rust what float ABIis being used so therefore we pessimistically assume that`x86_64-unknown-none` is using a soft-float ABI. This is incompatiblewith libcalls unless they aren't actually called which is only possiblewhen sufficiently many target features are enabled.The goal of this commit is to be a relatively low-effort way to place aroadblock in the way of "ok ABIs are weird" but at the same time enablegetting around the roadblock easily. Additionally the roadblock pointsto documentation about itself to learn more about what's going on here.Closes #11506* Add audit of raw-cpuid* Add back in checkTurns out it doesn't go through the same path as other bits* Review comments* Fix running floats without without custom support List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs

1f6c3aad - chore: fix typos (#11548)

Wed, 27 Aug 2025 10:54:21 +0000

chore: fix typos (#11548) List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs

c7308165 - docs: fix typo (#11488)

Thu, 21 Aug 2025 16:36:25 +0000

docs: fix typo (#11488)* Update wasi.rs* Update mod.rs* Update adapt.rs List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.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/examples/min-platform/embedding/src/wasi.rs

d41b0a71 - Use `Waker::noop` from Rust 1.85 (#10804)

Thu, 22 May 2025 16:19:12 +0000

Use `Waker::noop` from Rust 1.85 (#10804)Now possible after #10785 List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.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/examples/min-platform/embedding/src/wasi.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/examples/min-platform/embedding/src/wasi.rs

73992063 - refactor: move wasip2 implementation to `wasmtime_wasi::p2` (#10073)

Tue, 15 Apr 2025 18:34:39 +0000

refactor: move wasip2 implementation to `wasmtime_wasi::p2` (#10073)* refactor: move `wasmtime-wasi` p2-specific functionality to `p2`Signed-off-by: Roman Volosatovs * doc: move some of the p2 comments to top-levelSigned-off-by: Roman Volosatovs * chore: shorten `network` and `filesystem` module namesSigned-off-by: Roman Volosatovs ---------Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs

073aedab - Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

Wed, 09 Apr 2025 21:06:59 +0000

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They're toobig at this time to do through this PR. My hope is that one day in thefuture they'll be migrated, but more realistically that probably won'thappen so these crates just won't benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs

b9b0ba49 - add wasmtime-wasi-io and custom async executor to min-platform example (#10128)

Tue, 28 Jan 2025 19:35:07 +0000

add wasmtime-wasi-io and custom async executor to min-platform example (#10128)* add wasmtime-wasi-io and custom async executor to min-platform example* make it possible to find example from wasmtime-wasi-io docsprtest:full* fix comment* add wasm32-wasip2 target for min-platform ciand enable signals based traps when running with wasi disabled,because at the moment without signals based traps no native code can beloaded so the embedding never actually executes wasm. this ensures theheap size setting when not(feature = "wasi") is checked by execution* fix cbindgen version in ci List of files: /wasmtime-44.0.1/examples/min-platform/embedding/src/wasi.rs