<?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 exceptions.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><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/tests/all/exceptions.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/tests/all/exceptions.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>41e71699 - Exceptions: fix panic in `is_vmgcref_type()` for `HeapType::Exn`. (#11535)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/exceptions.rs#41e71699</link>
        <description>Exceptions: fix panic in `is_vmgcref_type()` for `HeapType::Exn`. (#11535)* Exceptions: fix panic in `is_vmgcref_type()` for `HeapType::Exn`.Fixes #11529 (for real this time).* Add test.

            List of files:
            /wasmtime-44.0.1/tests/all/exceptions.rs</description>
        <pubDate>Mon, 25 Aug 2025 20:16:37 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>bbd5b1f4 - Support exceptions with Pulley (#11495)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/exceptions.rs#bbd5b1f4</link>
        <description>Support exceptions with Pulley (#11495)* Support exceptions with PulleyThis implements Chris&apos;s suggestion to avoid special-casing the `raise`libcall and instead let it fully execute for Pulley. The switch ofwhether to do a native longjmp or a Pulley longjmp is done based on theinterpreter state of Wasmtime&apos;s configured executor.Closes #11486prtest:full* Resolve a TODO* Ignore tests on miri that compile wasm* Fix configured builds* Undo typo* Fix another typo

            List of files:
            /wasmtime-44.0.1/tests/all/exceptions.rs</description>
        <pubDate>Thu, 21 Aug 2025 22:20:13 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2d25f862 - WebAssembly exception-handling support. (#11326)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/exceptions.rs#2d25f862</link>
        <description>WebAssembly exception-handling support. (#11326)* WebAssembly exception-handling support.This PR introduces support for the [Wasm exception-handling proposal],which introduces a conventional try/catch mechanism to WebAssembly. ThePR supports modules that use `try_table` to register handlers for alexical scope; and provides `throw` and `throw_ref` that allocate (inthe first case) and throw exception objects.This PR builds on top of the work in #10510 for Cranelift-levelexception support, #10919 for an unwinder, and #11230 for exceptionobjects built on top of GC, in addition a bunch of smaller fix andenabling PRs around those.[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/prtest:full* Permit UnwindToWasm to have unused fields in Pulley builds (for now).* Resolve miri-caught reborrowing issue.* Ignore exceptions tests in miri for now (Pulley not supported).* Use wasmtime_test on exceptions tests.* Get tests passing on pulley platforms* Add a check to `supports_host` for the generated test and assert  failure also when that is false.* Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]`* Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]`* Remove miri annotations as they fall out of `#[wasmtime_test]`* Remove dead import* Skip some unsupported tests entirely in `#[wasmtime_test]`If the selected compiler doesn&apos;t support the host at all then there&apos;s noneed to run it. Actually running it could misinterpret `CraneliftNative`as &quot;run with pulley&quot; otherwise, so avoid such false negatives.* Cranelift: dynamic contexts: account for outgoing-args area.---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/tests/all/exceptions.rs</description>
        <pubDate>Thu, 21 Aug 2025 02:55:44 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
</channel>
</rss>
