Changes in cli.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/crates/wasi/src/cli.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/crates/wasi/src/cli.rs

d73bd632 - Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)

Fri, 09 Jan 2026 17:28:46 +0000

Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)* Migrate wiggle and wiggle generate to `wasmtime::error`* Fix testing `wiggle` and `wiggle-test` in isolationWhen doing plain old `cargo test -p wiggle` (or `wiggle-test`) the test wouldfail due to linking errors because Wasmtime's `std` cargo feature (and maybeothers) wasn't being enabled. The crate's tests would pass when run as part ofthe whole workspace, however, because of cargo feature resolution and othercrates that enabled the necessary features, which is why CI is green.* Remove direct anyhow dependency in wiggle-test* Migrate wasi-nn to `wasmtime::error`* Migrate wasi-keyvalue to `wasmtime::error`* Migrate wasi-io to `wasmtime::error`* Migrate wasi-http to `wasmtime::error`* Migrate wasi-config to `wasmtime::error`* Migrate wasi-common to `wastime::error`This is another interesting one because wasi-common is used internally toWasmtime but also by other projects. Therefore, rather than using`wastime::error::*` and making `wasmtime` a hard dependency, we use just`wasmtime_environ::error`.* cargo fmt* Migrate wasmtime-wasi to `wasmtime::error` List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs

e017b7f6 - Expand some docs on wasmtime-wasi (#11598)

Wed, 03 Sep 2025 18:34:29 +0000

Expand some docs on wasmtime-wasi (#11598)Add public docs for APIs added in #11593 and additionally internalizesome crate fields to avoid exposing too many internal implementationdetails. List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs

cf688861 - Make some WASI types public (#11593)

Tue, 02 Sep 2025 20:31:06 +0000

Make some WASI types public (#11593)If these are private it's impossible to implement a version of `add_to_linker()` that only pulls in some of this WASI implementation (e.g if you want to provide a custom implementation of some parts of it). List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs

7315a822 - Mirror WASIp{2,3} cli implementations (#11378)

Tue, 05 Aug 2025 16:18:04 +0000

Mirror WASIp{2,3} cli implementations (#11378)* Mirror WASIp{2,3} cli implementationsThis is an implementation of #11362 but for the `wasi:cli`implementation of WASIp2.* Fix unused field without p3 List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs

e6a662b3 - Share stdio implementations in WASIp{2,3} (#11368)

Fri, 01 Aug 2025 23:40:08 +0000

Share stdio implementations in WASIp{2,3} (#11368)* Share stdio implementations in WASIp{2,3}This commit is a refactoring of the`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more code. Thegeneric trait object that represents stdio now has the ability toacquire either a p2 stream or an async-based stream. The acquisition ofp2 has a default implementation so in the future this can be primarily`Async{Read,Write}`-based.Many trait implementations and types and such were all consolidatedtogether into the `wasmtime_wasi::cli` module. One-off implementationsin p2/p3 are now shared in one location and `WasiCtxBuilder` no longerneeds any generics for different stdio streams.Functionally this necessitated the addition of `Async{Read,Write}`implementations for some "base" implementations of stdio primitives.Implementations were mostly trivial except for a few adapters which weresignificantly more complicated, namely the `Async{Read,Write}Stream`adapter which converts a single `Async{Read,Write}` into the stdio of acomponent.Finally the stdin implementation for p3 was refactored to avoid use of`tokio::io::stdin()` which generally isn't safe to use. It's replacedwith a custom `AsyncRead` using the worker thread implementation we havein the crate already.Eventually I hope to remove the distinction between `p{2,3}::WasiCtx`and have these be the same type. This will make it nicer to only have asingle `WasiView` trait and additionally make it easier tosimultaneously implement all of WASIp{1,2,3}.* Fix build of C API* Fix build of `wasmtime serve` List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs

a5ed9fb4 - feat(wasip3): implement `wasi:cli` (#11257)

Fri, 18 Jul 2025 10:55:37 +0000

feat(wasip3): implement `wasi:cli` (#11257)* feat(wasi): introduce common CLI contextSigned-off-by: Roman Volosatovs * chore(wasi): implement traits for boxed valuesSigned-off-by: Roman Volosatovs * chore(wasi): implement `Default` for common WASI builderSigned-off-by: Roman Volosatovs * feat(wasip3): implement `wasi:cli`Signed-off-by: Roman Volosatovs * refactor: require streams to be `Send`Signed-off-by: Roman Volosatovs * refactor: avoid typing `WasiCli` in taskSigned-off-by: Roman Volosatovs * refactor: remove `Unpin` bound from stream I/OSigned-off-by: Roman Volosatovs * refactor: remove `ResourceView`Signed-off-by: Roman Volosatovs * chore: update `serve` to new WASI `isatty` APISigned-off-by: Roman Volosatovs * chore: adapt to stream API changesSigned-off-by: Roman Volosatovs * refactor: avoid `**` syntaxSigned-off-by: Roman Volosatovs * refactor(wasip3): remove `Impl` wrappersSigned-off-by: Roman Volosatovs * refactor(wasip3): use shorthand closure syntaxSigned-off-by: Roman Volosatovs * chore: account for different env on different targetsprtest:fullSigned-off-by: Roman Volosatovs ---------Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasi/src/cli.rs