<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in error.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>511638f5 - Refactor `wasi:http` headers&apos; host representation (#12754)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasi-http/src/p2/error.rs#511638f5</link>
        <description>Refactor `wasi:http` headers&apos; host representation (#12754)* Refactor `wasi:http` headers&apos; 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`&apos;d and is cheaply clonable.  `FieldMap` itself now tracks whether it&apos;s mutable or immutable (WASI  semantics) and doesn&apos;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&apos;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/p2/error.rs</description>
        <pubDate>Tue, 10 Mar 2026 21:49:13 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>365e2d89 - Refactor WASIp2 `wasi:http` implementation  (#12748)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasi-http/src/p2/error.rs#365e2d89</link>
        <description>Refactor WASIp2 `wasi:http` implementation  (#12748)* Sequester WASIp2 in `wasmtime-wasi-http` to a moduleThis mirrors the `wasmtime-wasi` crate&apos;s organization where there&apos;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&lt;T&gt;` structure is removed in favor ofas `WasiHttpCtxView&lt;&apos;_&gt;` 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&apos;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&apos;s`WasiHttpCtx` structure (which has field limits for example). WASIp3&apos;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&apos;s a `Default for &amp;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/p2/error.rs</description>
        <pubDate>Tue, 10 Mar 2026 16:24:22 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
