<?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 oracles.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>071c4061 - winch: implement ref.null, ref.is_null, ref.func, and typed select (#12940)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#071c4061</link>
        <description>winch: implement ref.null, ref.is_null, ref.func, and typed select (#12940)* winch: implement ref.null, ref.is_null, ref.func, and typed select* add disas tests and ref.func call_indirect coverage* register wasmtime module in fuzz wast_test to fix wast_smoke_test

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 02 Apr 2026 19:48:19 +0000</pubDate>
        <dc:creator>r-near &lt;163825889+r-near@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>46780983 - Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#46780983</link>
        <description>Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)* Exceptions: add exception-specific (command-sequence) fuzzer.This fuzzer uses a description of a set of &quot;scenarios&quot;, arbitrarilygenerated, to produce a specific kind of module that tests throw/catchbehavior. The module contains a chain of functions that invoke eachother; one will throw, and the rest may have catch clauses that do ordo not catch.* Review feedback.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Wed, 01 Apr 2026 22:26:11 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>2f7dbd61 - PCC: remove proof-carrying code (for now?). (#12800)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#2f7dbd61</link>
        <description>PCC: remove proof-carrying code (for now?). (#12800)In late 2023, we built out an experimental feature calledProof-Carrying Code (PCC), where we attached &quot;facts&quot; to values in theCLIF IR and built verification of these facts after lowering tomachine instructions. We also added &quot;memory types&quot; describing layoutof memory and a &quot;checked&quot; flag on memory operations such that we couldverify that any checked memory operation accessed valid memory (asdefined by memory types attached to pointer values viafacts). Wasmtime&apos;s Cranelift backend then put appropriate memory typesand facts in its IR such that all accesses to memory (aspirationally)could be checked, taking the whole mid-end and lowering backend ofCranelift out of the trusted core that enforces SFI.This basically worked, at the time, for static memories; but never fordynamic memories, and then work on the feature lostprioritization (aka I had to work on other things) and I wasn&apos;t ableto complete it and put it in fuzzing/enable it as a production option.Unfortunately since then it has bit-rotted significantly -- as we addnew backend optimizations and instruction lowerings we haven&apos;t keptthe PCC framework up to date.Inspired by the discussion in #12497 I think it&apos;s time to deleteit (hopefully just &quot;for now&quot;?) unless/until we can build it again. Andwhen we do that, we should probably get it to the point of validatingrobust operation on all combinations of memory configurations beforemerging. (That implies a big experiment branch rather than a bunch ofeager PRs in-tree, but so it goes.) I still believe it is possible tobuild this (and I have ideas on how to do it!) but not right now.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Tue, 31 Mar 2026 04:36:33 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>06be7808 - Clean up `gc_ops` fuzzing mutator (#12533)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#06be7808</link>
        <description>Clean up `gc_ops` fuzzing mutator (#12533)* Clean up `gc_ops` fuzzing mutatorThis commit cleans up a few random things about the `gc_ops` fuzzing mutator,notably:* The macro to define `GcOp` and many of its methods is refactored to be more  extensible going forward (e.g. all of GC op `fixup` is now macro-generated,  instead of having special-cases for typed struct ops, and we could probably  also move encoding into the macro as a follow up PR).* Furthermore, the macro is also a `for_each_*`-style macro now, which lets us  define the GC ops once and then use the macro multiple times to define  different things, rather than being forced to put everything we want to  generate into one macro RHS. This should make things a bit easier to read and  edit and plays nicer with LSP.* A bunch of GC op filtering that was logically part of fixing up an instruction  is now actually part of `GcOp::fixup`. Also a redundant `op.fixup()` call was  removed, `GcOp::fixup` takes `&amp;self` instead of `&amp;mut self` since it returns a  new `GcOp` now instead of mutatint `self` in place, etc...* A few other small things here and there.* Fix `GcOps` fuzz mutator testsAlso remove the `test_wat_string` test because it isn&apos;t really helpful at thispoint, it is just something we have to remember to update whenever weadd/remove/change `GcOp`s while not giving us anything in return.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 05 Feb 2026 19:19:00 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>6592cf93 - Struct locals etc (#12513)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#6592cf93</link>
        <description>Struct locals etc (#12513)* Add structref local/global/table access for structs* The number of iters back to 2048* Remove forgotten struct_num_local from limits* Address initial reviews* Idiomatic comments

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Wed, 04 Feb 2026 21:52:37 +0000</pubDate>
        <dc:creator>Khagan (Khan) Karimov &lt;127453117+khagankhan@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>cc8d04f4 - Remove need for explicit `Config::async_support` knob  (#12371)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#cc8d04f4</link>
        <description>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 &quot;old async&quot; and&quot;new async&quot; 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 &quot;locked&quot; during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to &quot;new async&quot; 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 &quot;this thing requires `async` stuffinternally.&quot; 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&apos;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&apos;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 &quot;requires async&quot; 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&apos;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&apos;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&apos;s leftfor future refactorings however.prtest:full* Review comments* Fix CI failures

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Fri, 23 Jan 2026 02:46:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>93d22fcd - Migrate fuzzing to `wasmtime::error` (#12263)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#93d22fcd</link>
        <description>Migrate fuzzing to `wasmtime::error` (#12263)* Migrate fuzzing to `wasmtime::error`* fix

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Wed, 07 Jan 2026 21:51:23 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>fee9be21 - Add a new fuzzer focused on component-model-async events (#12119)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#fee9be21</link>
        <description>Add a new fuzzer focused on component-model-async events (#12119)* Add a new fuzzer focused on component-model-async eventsThis commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtimewhich is focused on async events and interleavings of components usingthe component-model-async proposal. This fuzzer works by having aprecompiled guest program which serves as the component to run. Thisprecompiled component has a custom `fuzz.wit` which is used to interfacewith the fuzzer itself. The fuzzer is then a fuzz-generated sequence ofcommands to send to the component which verifies that everythingexecutes correctly, has no panics, etc.This fuzzer intends to stress async communication and taskinfrastructure with component-model-async. Notably this does not stresslifting/lowering or arbitrary type signatures. This does, however,permute all of the following:* Guest/host interactions (also guest/guest, host/host, etc).* Async functions, both ready and pending.* Future operations: reads, writes, cancellation, transfers, etc.* Stream operations: reads, writes, cancellation, transfers, etc.This is all throwing into a large &quot;soup&quot; and then asserted to workcorrectly. There&apos;s a few gotchas here and there for how this fuzzer isdesigned, such as some events requiring &quot;yield N times to await thisevent happening&quot;. This is required because Wasmtime is allowed tonon-deterministically select between a number of &quot;ready events&quot; and whatto dispatch.This is not intended to be a one-size-fits-all fuzzer forcomponent-model-async. The recent enhancements to the `component_api`fuzzer are intended to complement this fuzzer in terms of what&apos;sstressed where internally.* Review comments

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Tue, 09 Dec 2025 19:32:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>0a55f804 - &quot;Downgrade&quot; threads support to tier 2, disable fuzzing (#12036)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#0a55f804</link>
        <description>&quot;Downgrade&quot; threads support to tier 2, disable fuzzing (#12036)* &quot;Downgrade&quot; threads support to tier 2, disable fuzzingThis commit is borne out of a fuzz bug that was opened recently. Thefuzz bug specifically has to do with fallout from #12022, specifically`SharedMemory` being used to allocated instead of `Memory`. In thissituation the resource limiter is no longer consulted meaning thatshared memories bypass this and aren&apos;t caught by OOM checks. This iscurrently by design because `SharedMemory` instances don&apos;t know whichresource limiter to hook into per-store.More generally though the implementation of wasm threads, while workablein Wasmtime, has a number of known relatively large deficiencies. Thesewere not resolved prior to ungating the wasm proposal (that&apos;s on me) butnevertheless the quality of implementation is not quite up to &quot;tier 1par&quot; with the rest of what Wasmtime offers. Given this the threadsproposal is now downgraded to tier 2. To help minimize the impact ofthis the wasm proposal is left enabled-by-default, but creation of a`SharedMemory` in the Rust API requires opting-in via a new`Config::shared_memory` method.This commit shuffles around some documentation of wasm proposals tosplit it into tier 1/2/3 instead of on/off-by-default and then adds acolumn for whether the proposal is on-by-default.* clangformat* Fix tests* Add tests for failed creationFix an issue where defined shared memories weren&apos;t gated* Sync disabled threads stub* Fix another testprtest:full* Fix fuzzing tests* Fix dwarf tests

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Mon, 24 Nov 2025 17:09:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>5730c760 - Improve `Config`-related coverage of `component_api` (#12049)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#5730c760</link>
        <description>Improve `Config`-related coverage of `component_api` (#12049)This commit improves the preexisting `component_api` fuzz target to usearbitrary `Config` data. This, for example, helps exercise Pulley inaddition to native. In general this also helps stress and ensure that noconfig knobs are accidentally breaking ABI assumptions.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Fri, 21 Nov 2025 17:04:17 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>0b9ff9bf - Add async to the component_api fuzzer (#12047)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#0b9ff9bf</link>
        <description>Add async to the component_api fuzzer (#12047)This commit extends the preexisting `component_api` fuzzer in Wasmtimeto support `async`. This required a fair bit of refactoring to how thefuzzer worked but the basic idea remains the same. This fuzzergenerates:* An arbitrary component-model type signature (minus  resources/futures/streams)* A component which imports a function of this signature from the host  and exports a function of this signature to the host.* Internally the export is implemented with a component `caller` that  imports/exports this function signature.* The `caller` component is instantiated with a `callee` component that  imports/exports this function signature.* The `callee` component is instantiated with the host.In essence a component model value is threaded into a component, toanother composed component, then back out to the host. The return valuethen makes its way back through the same channel. The fuzz test ensuresthat the parameters received in the host import are the same as thosepassed to the export. Additionally the return value of the export isensured to be the same as the one that the host import returned. Inessence this is testing ABI handling in Wasmtime to ensure thatcomposition works correctly in addition to lifting/lowering code.This fuzzer additionally has a &quot;static&quot; and &quot;dynamic&quot; mode where, atcompile time, N components are generated with different signatures anduse the &quot;typed&quot; APIs of Wasmtime. For &quot;dynamic&quot; `Val` is used to testand arbitrary components are generated at fuzz-time. The fuzzer finallyexecutes this roundtrip in a loop multiple times in one fuzz test caseto test different runtime-shapes of values in addition tocompile-time-shapes of values.The main addition in this commit is to extend all of this with the asyncABI. The following knobs were added and implemented:* The function type used for the root component export, the function  between the composed components, and the function imported from the  host all have the ability to be an `async` function type now.* The lifts/lowers, in all locations, can be configured with the various  ABIs supported (e.g. sync, async-callback, or async-stackful for  lifts, and sync/async for lowers).* Like before the string encoding can be varied between the components  as well.This is intended to stress combining different flavors of ABI withdifferent behaviors to ensure that all the various paths throughoutWasmtime and such are hit. The goal of this fuzzer is to stress ABIlifting/lowering, so this is not handling much related to async eventscheduling (that&apos;s for a future fuzzer).In a follow-up commit I hope to extend this fuzzer with some async eventscheduling nonetheless. For example the fuzzer will generate an asyncyield point before/after calling `task.return` or before/after callingthe host import. That is intended to stress `first_poll`-vs-not behavioras it relates to ABI handling. None of that is yet implemented and forthis fuzzer async calls are assumed to always succeed immediately for now.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Wed, 19 Nov 2025 20:51:51 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>882f22a7 - Cleanup/add some testing in `wasmtime-fuzzing` (#12038)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#882f22a7</link>
        <description>Cleanup/add some testing in `wasmtime-fuzzing` (#12038)Share the fuzz-generator-helpers across more tests and add smoke testsfor the dynamic/static component API tests too.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Tue, 18 Nov 2025 17:04:40 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b6f59f05 - Split modules (#11993)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#b6f59f05</link>
        <description>Split modules (#11993)* Split GC to different modules and rename table_ops to gc_ops* Remove table_ops from fuzz_targets. Renamed to gc_ops* Address formatting failures

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Fri, 07 Nov 2025 17:09:47 +0000</pubDate>
        <dc:creator>Khagan (Khan) Karimov &lt;127453117+khagankhan@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>250b9922 - Add generic/typed `take_struct` imports + ops (#11713)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#250b9922</link>
        <description>Add generic/typed `take_struct` imports + ops (#11713)* add generic/typed take_struct imports + ops* Address clippy error* Address comments. Split GC related codes to its own modules. Update TableOps to GcOps as well as other related methods or DSs* Remove table ops* Revert &quot;Remove table ops&quot;This reverts commit 0634e51bfa88c0c1c73c28b5b4704c1a5e923c04.* Revert &quot;Address comments. Split GC related codes to its own modules. Update TableOps to GcOps as well as other related methods or DSs&quot;This reverts commit e1d2bd05eadad26366293919a3b70fad9f0628c3.* Address feedback and immediate generator crashes---------Co-authored-by: khan22 &lt;khan22@node0.gc.randtest-pg0.utah.cloudlab.us&gt;

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 06 Nov 2025 18:22:42 +0000</pubDate>
        <dc:creator>Khagan (Khan) Karimov &lt;127453117+khagankhan@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>23b9f3b0 - Add `--async[=true|false]` flag to `wast` CLI (#11953)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#23b9f3b0</link>
        <description>Add `--async[=true|false]` flag to `wast` CLI (#11953)This was needed to reproduce a fuzz bug recently and seemed like a goodpiece of functionality to have.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 30 Oct 2025 09:57:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>92126c50 - Add first-class type access of `component::Func` (#11943)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#92126c50</link>
        <description>Add first-class type access of `component::Func` (#11943)When `Func:::{params,results}` was added we didn&apos;t have`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it&apos;scheaper and easier to access and work with that instead of the one-offaccessors on `Func`.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Mon, 27 Oct 2025 21:25:35 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>87d1730b - Supply type information in `func_new` for components (#11944)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#87d1730b</link>
        <description>Supply type information in `func_new` for components (#11944)Originally the `Linker::func_new` type for components was modeled aftercore wasm where a type was provided when the type was defined. This wasdifficult, however, because there&apos;s no way to construct types right nowand instead a component had to be created and compiled to acquire typeinformation from it. Later various refactorings meant that it waspossible to drop the type information entirely from `func_new` meaningthat it was &quot;typeless&quot; in a sense, and the functionality relied on thetagged nature of `Val` which always knows its type.This has proven a bit difficult to integrate into Python in some workI&apos;ve been doing. Namely in Python component values are (at least IMO)best represented as native Python values where possible. Native Pythondoesn&apos;t distinguish, however, between integer bit widths (orsignededness). This means that converting a Python value to a componentvalue requires type information to guide the conversion process.Currently when defining a function in a linker there&apos;s no way to get atthis type information meaning that the types would need to be suppliedin Python, bringing up the same shortcomings of not being able to createtypes.In lieu of filling out type constructors, which is itself quitenontrivial, I&apos;ve opted to do the next-most-easiest thing which is tosupply the type to the callee when an import is invoked. This means thatthe callee has all the type information necessary. While this issomewhat costly in that it clones a few arcs it&apos;s expected to be a dropin the bucket compared to the inefficiencies of `Val` so it&apos;s at leastin the same spirit of the cost of the API right now.My intention is to use this to update the C API for components andeventually end up with type information when Python is invoked inwasmtime-py. Also while I&apos;m using wasmtime-py as a motivating case herethat&apos;s sort of just one example of a host embedding which doesn&apos;t havethe full fidelity of Rust&apos;s type system and might benefit from this.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Mon, 27 Oct 2025 21:25:15 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>6a66b9a0 - Put each component in its own store in wast testing (#11686)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#6a66b9a0</link>
        <description>Put each component in its own store in wast testing (#11686)This commit refactors the `wasmtime-wast` crate to place each componentin its own store. This is in contrast to core wasm testing where allinstances get placed in the same store. The reason for this is thatcomponents, in particular async state, is only fully defined so long asa trap doesn&apos;t happen and once a trap happens it&apos;s expected the entirestore is torn down. This removes the need for the store to keep track ofexactly which instance all async tasks are associated with to ensurethat once any of them trap only the precise set of tasks necessary aretorn down. Instead Wasmtime can rely on embedders throwing away`Store&lt;T&gt;` entirely.The refactoring here provides a hook in `WastContext` to configure thestore but otherwise a new store is manufactured for all componentinstances. Core wasm is unaffected. Tests are also unaffected assame-store behavior isn&apos;t actually required by any tests.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 11 Sep 2025 20:51:13 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ecda6e33 - Fuzzing: ignore thrown exceptions during instantiation. (#11554)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#ecda6e33</link>
        <description>Fuzzing: ignore thrown exceptions during instantiation. (#11554)This updates the instantiation logic to ignore inputs that throw anexception during instantiation, just as it does for other kinds oferrors such as traps currently.Fixes #11551.

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Thu, 28 Aug 2025 01:10:32 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>3aa39239 - Exceptions: add basic support for fuzzing. (#11511)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/fuzzing/src/oracles.rs#3aa39239</link>
        <description>Exceptions: add basic support for fuzzing. (#11511)* Enable use of exceptions in our fuzz module generator.This patch was provided by Alex in #11505; it is thusCo-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;* Add ExnRef comparison to differential result checking.---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/fuzzing/src/oracles.rs</description>
        <pubDate>Fri, 22 Aug 2025 17:24:40 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
</channel>
</rss>
