<?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 suspend-trap.wast</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>da093747 - Relax panics in async/futures to traps/errors (#12688)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/misc_testsuite/component-model-threading/suspend-trap.wast#da093747</link>
        <description>Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don&apos;t believe we&apos;re going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we&apos;reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn&apos;t actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare &quot;first class traps&quot;, or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I&apos;ve performeda few refactorings here as well.* Some traps previously present as error strings are now promoted to  using `Trap::Foo` instead. This has some refactoring of the Rust/C  side as well to make it easier to define new variants. Tests were  additionally added for any trap messages that weren&apos;t previously  tested as being reachable.* A new `bail_bug!` macro was added (internally) for Wasmtime. This is  coupled with a concrete `WasmtimeBug` error type (exported as  `wasmtime::WasmtimeBug`). The intention is that `bail!` continues to  be &quot;here&apos;s a string and I&apos;m a bit too lazy to make a concrete error&quot;  while `bail_bug!` indicates &quot;this is a bug in wasmtime please report  this if you see it&quot;.The rough vision is that if an error condition is reached, and the systemis not broken in such a way that panicking is required, then `bail_bug!`can be used to indicate a bug in Wasmtime as opposed to panicking. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for &quot;return a trap, lockdown the store, and let destructors take care of everything else&quot;.This change additionally has resulted in API changes for `FutureReader`and `StreamReader`. For example creation of these types now returns a`Result` for when the `ResourceTable` is full, for example, instead ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics

            List of files:
            /wasmtime-44.0.1/tests/misc_testsuite/component-model-threading/suspend-trap.wast</description>
        <pubDate>Mon, 02 Mar 2026 21:26:40 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
