Changes in lib.rs

511638f5 - Refactor `wasi:http` headers' host representation (#12754)

Tue, 10 Mar 2026 21:49:13 +0000

Refactor `wasi:http` headers' host representation (#12754)* Refactor `wasi:http` headers' host representationThis commit is a follow-on/extension of #12748 and extends the changesmade for WASIp2 headers in #12652 to the WASIp3 implementation as well.This is done through a number of refactorings to make the WASIp2 andWASIp3 implementations more similar in terms of how they representheaders. Changes here are:* `FieldMap` now has its own dedicated module at the crate root instead of intermingling with other WASIp2 types.* `FieldMap` is now internally-`Arc`'d and is cheaply clonable. `FieldMap` itself now tracks whether it's mutable or immutable (WASI semantics) and doesn't need different wrappers in WASIp2 and WASIp3.* Creation of an immutable `FieldMap` can be done without needing a size limit. Flagging a `FieldMap` as mutable, however, requires a size limit.* `FieldMap::set` was added to be a bit more efficient w.r.t. clones.* `FieldMapError` is a new error type that covers all of the possible error modes of operating with a `FieldMap`. Conversions from this to WASIp{2,3} `header-error` types are now implemented as well.* WASIp2 now flags `header-error` as a trappable-error-type, allowing the use of `?` in implementing header functions (like WASIp3).* Much of WASIp2's header implementation was refactored with `?`, moving methods around, shuffling where headers are made vs `FieldMap`, some minor idioms, etc.* WASIp3 no longer uses `MaybeMutable` for headers and instead uses `FieldMap` directly.cc #12674* Clippy warnings List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

365e2d89 - Refactor WASIp2 `wasi:http` implementation (#12748)

Tue, 10 Mar 2026 16:24:22 +0000

Refactor WASIp2 `wasi:http` implementation (#12748)* Sequester WASIp2 in `wasmtime-wasi-http` to a moduleThis mirrors the `wasmtime-wasi` crate's organization where there's a`p2` module and a `p3` module at the top level.* Refactor WASIp2 `wasi:http` implementationThis commit reorganizes and refactors the WASIp2 implementation of`wasi:http` to look more like other `wasmtime-wasi`-style interfaces.Specifically the old `WasiHttpImpl` structure is removed in favor ofas `WasiHttpCtxView<'_>` type that is used to implementbindgen-generated `Host` traits. This necessitated reorganizing themethods of the previous `WasiHttpView` trait like so:* The `WasiHttpView` trait is renamed to `WasiHttpHooks` to make space for a new `WasiHttpView` which behaves like `WasiView`, for example.* The `ctx` and `table` methods of `WasiHttpHooks` were removed since they'll be fields in `WasiHttpCtxView`.* Helper methods for WASIp2 were moved to methods on `WasiHttpCtxView` instead of default methods on `WasiHttpHooks`.With these changes in place the WASIp3 organization was also updatedslightly as well. Notably WASIp3 now contains a reference to the crate's`WasiHttpCtx` structure (which has field limits for example). WASIp3'sprevious `WasiHttpCtx` trait is now renamed to `WasiHttpHooks` as well.This means that there are two `WasiHttpHooks` traits right now, one forWASIp2 and one for WASIp3. In the future I would like to unify these twobut that will require some more work around the default `send_request`.A final note here is that the `WasiHttpHooks` trait previously, andcontinues to be, optional for embedders to implement. Default functionsare provided as `wasmtime_wasi_http::{p2, p3}::default_hooks`.Additionally there's a `Default for &mut dyn WasiHttpHooks`implementation, too.With all that outlined: the motivation for this change is to bring theWASIp2 and WASIp3 implementations of `wasi:http` closer together. Thisis inspired by refactorings I was doing for #12674 to apply the sameheader limitations for WASIp3 as is done for WASIp2. Prior to thischange there were a number of differences such as WASIp3 not having`crate::WasiHttpCtx` around, WASIp2 having a different organization ofstructures/borrows, etc. The goal is to bring the two implementationscloser in line with each other to make refactoring across them moreconsistent and easier.* Make `WasiHttp` in WASIp2 public* Fix some conditional build* Fix some doctests* Fix configured build* Fixup documentation List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.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-http/src/lib.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-http/src/lib.rs

85d8cc06 - Migrate wasi-http to `wasmtime::error` (#12291)

Thu, 08 Jan 2026 20:33:01 +0000

Migrate wasi-http to `wasmtime::error` (#12291)* 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` List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

dcd65446 - support WASIp3 instance reuse in `wasmtime serve` (#11807)

Mon, 20 Oct 2025 14:55:48 +0000

support WASIp3 instance reuse in `wasmtime serve` (#11807)* support WASIp3 instance reuse in `wasmtime serve`This is a draft implementation of WASIp3 instance reuse. Previously, we usedone store and one instance per request for both p2 and p3 handlers, discardingthe store and instance immediately after the request was handled. Now weattempt to reuse p3 instances and their stores instead, both serially andconcurrently.Advantages of reuse:- Higher throughput: We can amortize the time spent creating and disposing of instances and stores over a number of requests.- Lower memory and address space usage: Concurrent instance reuse allows us to handle more requests with fewer instances, especially when the handler is I/O bound.- Developers will presumably need to make changes to their applications anyway when migrating from p2 to p3, so this is an ideal time to change the default from no reuse to (some) reuse, assuming we want to do it at all.Disadvantages of reuse:- Reduced isolation: When the same instance is used to handle multiple requests, the blast radius of bugs in the guest is larger; a trap can affect unrelated requests, and a security flaw could leak state across requests.- Host implementation complexity: There's more code to manage and more configuration knobs to tune.- Guest implementation complexity: You can't just stash state in a global variable and call it a day. Similarly, shortcuts like using a leaking GC require additional thought.Given the tradeoffs, we'll definitely need to provide components a way to optout of reuse if desired. Seehttps://github.com/WebAssembly/wasi-http/issues/190 for related discussion.Implementation details:I've moved `ProxyHandler` from `wasmtime_cli::commands::serve` to`wasmtime_wasi_http::handler` (so it can be reused by custom embedders),abstracted away the `serve`-specific parts, and added support for instance reusevia a new `ProxyHandler::push` function. The `push` function takes a work itemrepresenting an incoming request and dispatches it to a dynamically sized poolof worker tasks, each with its own store and `wasi:http/handler@0.3.x` instance.Worker tasks accept work items as capacity allows until they either reach amaximum total reuse count or hit an idle timeout, at which point they exit.Performance:I've run a few benchmarks using `wasmtime-serve-rps.sh` and[hello-wasip3-http](https://github.com/dicej/hello-wasip3-http/blob/main/src/lib.rs)(a simple "hello, world" request handler). Highlights:- 45% more requests per second with instance reuse enabled vs. disabled- 64% fewer concurrent instances required for an I/O-bound handler - Here I added a 40ms delay to the "hello, world" handler to simulate I/OTODOs:- Support host-enforced request timeouts. Note that we can't simply use the epoch-based trap-on-timeout approach we've traditionally used since a given instance may be responsible for a number of concurrent requests. This will require adding a public API to the `wasmtime` crate for cleanly cancelling a guest task without affecting other ones.- Add CLI options for the configuration knobs (e.g. max request count per instance, idle timeout, etc.)- Use guest signals like `backpressure`, explicit `wasi:cli/exit/exit`, https://github.com/WebAssembly/wasi-http/issues/190, etc. to drive reuse decisionsSigned-off-by: Joel Dice * additional instance reuse supportThis addresses a couple of TODO items from my previous instance reuse PR:- Support request timeouts by gracefully shutting down the worker as soon as any request hits a timeout, letting any other pending tasks finish or time out before actually dropping the instance.- Convert the previously hard-coded config options to CLI options.- Enable profiling when instance reuse is enabled.Signed-off-by: Joel Dice * start worker tasks more aggressivelyThis improves `wasmtime serve` performance when instance reuse is enabled by:- spawning a worker task any time there are no idle workers available- considering a worker to be unavailable until it has finished initializing itselfSigned-off-by: Joel Dice * revert unecessary wasmtime-serve-rps.sh changesSigned-off-by: Joel Dice * enable WASIp2 instance reuseSigned-off-by: Joel Dice * add clarifying comments about when and why we start worker tasksSigned-off-by: Joel Dice * remove duplicated code in `ProxyHandler::spawn`By bypassing the task queue when there are no already-available workers, I'venarrowed the performance gap between the "fast path" code and the normal path toabout 2%, which is close enough that we can remove the duplicated code.Signed-off-by: Joel Dice * ensure timeouts enforced if event loop stallsThis fixes an issue such that timeouts weren't being reliably enforced when theguest either busy loops for an extended time or makes a sync call to a hostfunction that takes exclusive access to the `Store` and blocks for a while. Ineither of those cases, the `StoreContextMut::run_concurrent` event loop willstall, being unable to make progress while the task fiber monopolizes the`Store`. In this case, we must enforce timeouts _outside_ the event loop. Seethe new code comments for details on how that is done.This also tweaks `wasmtime serve` stderr/stdout output a bit to address`cli_tests::cli_serve_*` test regressions.Signed-off-by: Joel Dice * add reuse and timeout tests to `cli_tests`This adds several new integration tests which exercise various aspects of`wasmtime serve`'s instance reuse feature, including timeouts for p2-style(synchronous) sleeps and p3-style (asynchronous) sleeps.Signed-off-by: Joel Dice * fix foreach_api breakageSigned-off-by: Joel Dice * Minor cleanups to `handler.rs`* Don't use `FutureExt`, use `async { .. }` instead.* Don't use `T`, instead use `S::StoreData`.* Shift an `unreachable!()` to be closer to the "source"* add more comments to `handler.rs`These comments draw attention to a few of the more subtle aspects of the codeand the invariants it is upholding.Signed-off-by: Joel Dice * add docs regarding the `req_id` parameterSigned-off-by: Joel Dice * add comments regarding atomic load/store orderingsThis also changes one of the `SeqCst` orderings to `Relaxed`.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

4f2fa154 - Update nightly Rust used in CI (#11755)

Mon, 29 Sep 2025 18:12:14 +0000

Update nightly Rust used in CI (#11755)* Update nightly Rust used in CIKeeping it up-to-dateprtest:full* Fix unused warnings on nightly* Rename rustdoc feature* Adjust some removals List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

ddcd9b21 - Document all wasmtime-wasi-http features on docs.rs (#11754)

Mon, 29 Sep 2025 15:24:12 +0000

Document all wasmtime-wasi-http features on docs.rs (#11754)Similar to other crates, copy the configuration for this crate. List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

5a2860ce - p3-http: rework `content-length` handling (#11658)

Wed, 10 Sep 2025 14:21:03 +0000

p3-http: rework `content-length` handling (#11658)* p3-http: correctly handle `result` future cancellationSigned-off-by: Roman Volosatovs * p3-http: restructure the `content-length` test a bitSigned-off-by: Roman Volosatovs * test(http): keep accepting connections after errorsprtest:fullSigned-off-by: Roman Volosatovs * test(p3-http): assert `handle` error on exceeding `content-length`Signed-off-by: Roman Volosatovs * p3-http: perform `content-length` check earlySigned-off-by: Roman Volosatovs * test(p3-http): account for `handle` race conditionSigned-off-by: Roman Volosatovs * refactor(http): reuse `get_content_length`Signed-off-by: Roman Volosatovs * p3-http: check `content-length` for host bodiesSigned-off-by: Roman Volosatovs * doc(p3-http): call out that host bodies are not validatedSigned-off-by: Roman Volosatovs * p3-http: refactor body size error sendSigned-off-by: Roman Volosatovs * fix(p3-http): do not rely on `Drop` for host body checkSigned-off-by: Roman Volosatovs * doc(p3-http): ensure non-default send request is documentedSigned-off-by: Roman Volosatovs * doc(p3-http): correct `send_request` docSigned-off-by: Roman Volosatovs ---------Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

f3d72564 - p3-http: finish `wasi:http@0.3` implementation (#11636)

Tue, 09 Sep 2025 07:58:06 +0000

p3-http: finish `wasi:http@0.3` implementation (#11636)* refactor(p3-http): use trappable errorsSigned-off-by: Roman Volosatovs * feat(p3-http): implement `content-length` handlingSigned-off-by: Roman Volosatovs * refactor(p3-http): remove a few resource utilitiesSigned-off-by: Roman Volosatovs * remove unused test importSigned-off-by: Roman Volosatovs * fix(p3-http): close stream handles on dropSigned-off-by: Roman Volosatovs * test(p3-http): stream responses backThis is something we've been doing in wasip3, but I forgot to port thisoverSigned-off-by: Roman Volosatovs * doc(p3-http): add missing docs, internalize more, simplifySigned-off-by: Roman Volosatovs * refactor(p3-http): extract `Body::consume`Signed-off-by: Roman Volosatovs * refactor(p3-http): clean-up `content-length` error reportingSigned-off-by: Roman Volosatovs * refactor(p3-http): drop elided lifetimeSigned-off-by: Roman Volosatovs * fix(p3-http): avoid guest body deadlock hazardSigned-off-by: Roman Volosatovs * refactor(p3-http): add more docs, clean-upSigned-off-by: Roman Volosatovs * doc(p3-http): add more docsSigned-off-by: Roman Volosatovs * fix(p3-http): rework result future handlingMost importantly this avoids a race condition between `content-length` error observed by `GuestBody`and hyper I/O driverSigned-off-by: Roman Volosatovs * add new imports after rebaseSigned-off-by: Roman Volosatovs * clean-up `poll_consume`Signed-off-by: Roman Volosatovs * assert content-length `handle` resultsSigned-off-by: Roman Volosatovs * relax `content_length` test `handle` assertSigned-off-by: Roman Volosatovs ---------Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

6f6a514b - feat(p3): begin `wasi:http` implementation (#11439)

Fri, 15 Aug 2025 17:53:44 +0000

feat(p3): begin `wasi:http` implementation (#11439)* doc: fix typo in p3 filesystem refSigned-off-by: Roman Volosatovs * build: vendor `wasi:http@0.3.0` WITSigned-off-by: Roman Volosatovs * feat(p3-http): scaffold p3 implementationSigned-off-by: Roman Volosatovs * test(p3-http): add testsSigned-off-by: Roman Volosatovs * chore(p3-http): add utils used by p3 testsSigned-off-by: Roman Volosatovs * chore: add `expect` reasonsSigned-off-by: Roman Volosatovs * address review commentsSigned-off-by: Roman Volosatovs * establish `conn` connections on dropSigned-off-by: Roman Volosatovs ---------Signed-off-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

f7a5aa34 - Unify WASIp{2,3} context structures (#11370)

Sat, 02 Aug 2025 00:57:09 +0000

Unify WASIp{2,3} context structures (#11370)This removes `wasmtime_wasi::p{2,3}::{WasiCtx, WasiCtxBuilder,WasiView}` in favor of only having `wasmtime_wasi::{WasiCtx,WasiCtxBuilder, WasiView}` instead. Conceptually these revisions of WASIall provide the same functionality just with a different veneer that thecomponent model offers, so having only one way to configure host-sidebehavior will make it easier to both organize implementations internally(e.g. more sharing of code) as well as for embedders to configure (onlyone context to create/manage). List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

0a074afc - Simplify WASI internal implementations (#11365)

Fri, 01 Aug 2025 01:24:24 +0000

Simplify WASI internal implementations (#11365)* Simplify WASI internal implementationsThis commit migrates the WASIp2 implementation to be closer to theupcoming WASIp3 implementation in terms of how things are implementedinternally. Previously the way things worked with WASIp2 is:* Embedders call `add_to_linker` with `T: WasiView`* Internally `add_to_linker` is called which creates `WasiImpl<&mut T>`* All internal implementations were `impl Host for WasiImpl where T: WasiView`* A forwarding impl of `impl WasiView for &mut T` was requiredWhile this all worked it's a bit complicated for a few reasons:1. Dealing with generically named structures like `WasiImpl` (or `IoImpl` or `WasiHttpImpl`) is a bit baroque and not always obvious as to what's going on.2. The extra layer of generics in `impl Host for WasiImpl` adds a layer of conceptual indirection which is non-obvious.3. Other WASI proposal implementations do not use this strategy and instead use "view" types or `impl Host for TheType` for example.4. Internal incantations of `add_to_linker` had to deal with mixtures of `IoImpl` and `WasiImpl` and aligning everything just right.5. An extra layer of generics on all impls meant that everything was generic meaning that `wasmtime-wasi`-the-crate didn't generate much code, causing longer codegen times for consumers.The goal of this commit is to migrate towards the style of what WASIp3is prototyping for how impls are modeled. This is done to increase theamount of code that can be shared between WASIp2 and WASIp3. This has anumber of benefits such as being easier to understand and also beingmore modular where `wasi:clocks` implementations of traits don't requirefilesystem context to be present (as is the case today). This in theoryhelps a more mix-and-match paradigm of blending together various bitsand pieces of `wasmtime-wasi` implementations.Concretely the changes made here are:* `WasiView` no longer inherits from `IoView`, they're unrelated traits now.* `WasiView` now returns `WasiViewCtx<'a>` which has `ctx: &'a mut WasiCtx` and `table: &'a mut ResourceTable`. That means it basically does the same thing before but in a slightly different fashion.* Implementations of `Host` traits are now directly for `WasiCtxView<'_>` and don't involve any generics at all. These are hopefully easier to understand and also better from a codegen/compile-time perspective.* Embedders no longer need to implement `IoView` directly and instead fold that functionality into `WasiView`.* `WasiHttpView` no longer inherits from `IoView` and instead has a direct `fn table` method. Additionally `WasiHttpImpl` no longer embeds `IoImpl` inside of it.* Host traits for `wasi:io` are now implemented directly for `ResourceTable` instead of `IoImpl`.The immediate goal of this refactoring is to enable more sharing alongthe lines of #11362. This was not possible prior because WASIp3 requiresa simultaneous borrow on the table/ctx while the trait hierarchypreviously gave you one-or-the-other. With this new organization it willbe possible to get both at the same time meaning morestructure/contexts/etc can be shared between implementations.prtest:full* CI fixes* More CI fixes* More CI fixes List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

5ac3f799 - Cargo doc fixes (#11171)

Tue, 01 Jul 2025 21:52:28 +0000

Cargo doc fixes (#11171)* wasmtime-wasi-http: fix docs missing wasmtime_wasi::p2::add_to_linkerreported in https://bytecodealliance.zulipchat.com/#narrow/channel/219900-wasi/topic/Help.3A.20Wasmtime's.20runner.20for.20WASI-HTTP.20p2.20guest/with/526609626Unfortunately, this doc is no_run because it acts as a server daemon,and loads a component which doesnt exist. If the doc had been executedthis would have been caught.* wasmtime-wasi-http: other doc warning fixes* wasmtime-wasi: cargo doc fixes* Update crates/wasi-http/src/lib.rsCo-authored-by: Lann ---------Co-authored-by: Lann List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs

28b859a3 - Update to WASI 0.2.6. (#11049)

Mon, 16 Jun 2025 18:08:03 +0000

Update to WASI 0.2.6. (#11049)* Update to WASI 0.2.6.This includes two changes:# https://github.com/WebAssembly/wasi-filesystem/pull/165Documentation update# https://github.com/WebAssembly/wasi-http/pull/139Adds a new unstable `send-informational` function to the `response-outparam` resource. I've left this `unimplemented!()`.* Trap instead of panic List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.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/crates/wasi-http/src/lib.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/crates/wasi-http/src/lib.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/crates/wasi-http/src/lib.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/crates/wasi-http/src/lib.rs

ad21d958 - Don’t panic when http `handle` function returns before invoking `set` (#10387)

Wed, 12 Mar 2025 22:03:29 +0000

Don’t panic when http `handle` function returns before invoking `set` (#10387)* handle return before `set` call* move wasm32 gate* unify error messages List of files: /wasmtime-44.0.1/crates/wasi-http/src/lib.rs