<?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 lib.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><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/cli-flags/src/lib.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/cli-flags/src/lib.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>ab78bd82 - fix: correct various typos (#12807)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#ab78bd82</link>
        <description>fix: correct various typos (#12807)Signed-off-by: Ho Kim &lt;ho.kim@ulagbulag.io&gt;

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Sun, 22 Mar 2026 18:10:20 +0000</pubDate>
        <dc:creator>Ho Kim &lt;ho.kim@ulagbulag.io&gt;</dc:creator>
    </item>
<item>
        <title>133a0ef4 - Debugging: add the debug-main world. (#12756)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#133a0ef4</link>
        <description>Debugging: add the debug-main world. (#12756)* Debugging: add the debug-main world.This PR &quot;draws the rest of the owl&quot; for the debug-mainworld (bytecodealliance/rfcs#45). This includes a WIT world that hostsdebug components that have access to &quot;host debug powers&quot; via adebugging API, and the ability to load such a debug-component and giveit control of the main program as a debuggee when using `wasmtimerun`.The WIT is namespaced to `bytecodealliance:wasmtime` and is slightlyaspirational in places: for example, the host does not yet implementinjection of early return values or exception-throws. I intend to fillout a series of TODO issues once this all lands to track followup(&quot;post-MVP&quot;) work.This PR does not include any debug components. I separately have agdbstub component, with which I tested and co-developed this host-sideimplementation. My plan is to land it in a followup PR as a componentthat will be embedded in/shipped with the Wasmtime CLI and availableunder an easy-to-use CLI option. Once we have that gdbstub component,we can also implement end-to-end integration tests that boot up LLDBand run through an expected interaction. (Separately, thoseintegration tests will require a release of wasi-sdk to ship an LLDBbinary that we can use.) As such, there are no real tests in this PR:interesting behaviors only really occur with a full end-to-end flow.The integration with the CLI is a little awkward (we internally buildanother `wasmtime run` command that invokes the debug component, andtie it together with the debuggee via a special `invoke_debugger` API;this seemed less bad than reworking all of the WASI setup to be morereusable). Happy to take more ideas here.* Review feedback.* Review feedback.* Review feedback: update vendor-wit.sh.* Review feedback: -Ddebugger-arg= -&gt; -Darg=.* Review feedback.* Review feedback.* Review feedback: factor host.rs into several submodules.* Review feedback: rename Debugger to Debuggee on host side.* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.* Review feedback.* Review feedback.* Add simple debug-component tests.* Add wasm32-wasip2 target in a few places in CI* Cargo vets for wstd dependency.* Add wasm32-wasip2 in more places* fix debug-component test dependence on componentization byte offsets* Review feedback.* Fix cancel-safety of EventFuture.* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.* Review feedback.* Review feedback: strip down WASI imports in debugger world.* fold debugger test component back into wasip1 + adapter test artifact compilation flow

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Fri, 13 Mar 2026 18:58:17 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>1b59b579 - Add support for map type (#12216)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#1b59b579</link>
        <description>Add support for map type (#12216)* Add support for map typeSigned-off-by: Yordis Prieto &lt;yordis.prieto@gmail.com&gt;* Add Map and MapEntry classes to support key/value pairs in component modelThis commit introduces the Map and MapEntry classes, enabling the representation of map values in the component model. The Map class allows for the creation and iteration of key/value pairs, enhancing the functionality of the wasmtime component API. Additionally, the .gitignore file is updated to exclude build artifacts from the crates/c-api directory.* Add wasm_component_model_map configuration support* Format code* Format C code* Enhance component model to support HashMap&lt;K, V&gt; typeThis commit introduces support for HashMap&lt;K, V&gt; in the component model, allowing maps to be represented as list&lt;tuple&lt;K, V&gt;&gt; in the canonical ABI. It includes implementations for the ComponentType, Lower, and Lift traits for HashMap, enabling type checking, lowering to flat representations, and lifting from memory. Additionally, the maximum depth for type generation in the fuzzing utility is updated to accommodate the new map type.* Refactor component configuration to introduce map supportThis commit removes the previous wasm features configuration and adds new functions for creating a map-configured engine. The `map_config` and `map_engine` functions are introduced to facilitate the use of the component model with maps in tests, ensuring that the engine is properly configured for map types in the component model.* Add new WAST test for map types and remove map type definitions from existing testsThis commit introduces a new WAST test file specifically for testing various map types in the component model. Additionally, it removes the redundant map type definitions from the existing types.wast file to streamline the test suite.* Update component fuzzing and dynamic tests to replace call_and_post_return with call* Format code* Refactor HashMap usage in typed.rs to use wasmtime_environ collections* Fix HashMap initialization and insertion to handle potential errors in typed.rs* Refactor HashMap handling in typed.rs to use lower_map_iter for improved iteration and memory management. Introduce new implementations for ComponentType, Lower, and Lift traits for std::collections::HashMap, enhancing support for map types in the component model.* Fix map adapter trampoline compilation and alignment bugsThe translate_map function had two categories of bugs preventing mapadapter trampolines from working:1. Wasm stack discipline: local_set_new_tmp emits LocalSet which pops   from the stack, but was called when the stack was empty (to   &quot;pre-allocate&quot; locals). Fixed by computing values first, then   calling local_set_new_tmp to consume them&#8212;matching translate_list&apos;s   pattern. Also removed an erroneous LocalTee that left an orphan   value on the stack. Affected: src_byte_len, dst_byte_len,   cur_src_ptr, cur_dst_ptr.2. Pointer advancement: after value translation, the pointer still   points at the value start. The code only advanced by trailing   padding instead of value_size + trailing_padding, causing every   loop iteration to re-read the same memory.Also fixes entry layout to use proper record alignment rules (entryalign = max(key_align, value_align), value at aligned offset).* Refactor map entry layout calculations to use canonical ABI* Remove unnecessary clone of map pairs during loweringVal::Map already holds Vec&lt;(Val, Val)&gt; which derefs to &amp;[(Val, Val)],matching lower_map&apos;s signature directly. The intermediate Vec allocationand deep clone of every key/value pair was redundant.* Deduplicate map lift logic between HashMap implementations* Deduplicate list and map sequence translation scaffolding* Fix cargo fmt formatting issues* Deduplicate map typecheck logic* Deduplicate map lowering with linear_lower_map_to_flat and linear_lower_map_to_memory helpers* Clean up lift_try_map: use drop, move TryHashMap import to module scope* Fix CI: arbtest overflow and no-std HashMap lift_map- component_fuzz: use saturating_sub in generate_hashable_key to prevent  underflow when fuel is 0 and Enum variant is chosen- typed: remove incorrect ? operators in lift_map for hashbrown::HashMap  (with_capacity and insert don&apos;t return Result)* Store map tuple layout in TypeMapCompute map entry ABI and value offsets once during type building, and reuse that metadata in runtime map lift/lower paths instead of recalculating tuple layout at each call site.* Refactor map ABI argument passingBundle map lift/lower layout and type metadata into a small MapAbi32 helper so map helper calls stay concise without changing behavior.* Fix CI: enable component_model_map in fuzzing and handle map in arbitrary_valThe fuzzer&apos;s component_api oracle was generating map types but the enginedidn&apos;t have the map feature enabled, and arbitrary_val had no arm forType::Map. Enable component_model_map in the store helper (matching howcomponent_model_async is forced on) and implement arbitrary value generationfor map types.---------Signed-off-by: Yordis Prieto &lt;yordis.prieto@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Mon, 09 Mar 2026 23:34:21 +0000</pubDate>
        <dc:creator>Yordis Prieto &lt;yordis.prieto@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>301dc716 - Fix two security advisories. (#12652)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#301dc716</link>
        <description>Fix two security advisories. (#12652)* Fix two security advisories.This commit contains merged fixes for two security advisories inWasmtime:* GHSA-852m-cvvp-9p4w* GHSA-243v-98vx-264hThis introduces new knobs to Wasmtime to limit the scope of resourcesthat WASI implementations will allocate on behalf of guests. Unlikebackports to 41.0.x-and-prior these knobs all have default values whichare considered reasonable for hosts if they don&apos;t further tune them. Thefollowing CLI knobs have been added:* `-Smax-resources` - limits the total component-model resources a guest  can allocate in a table* `-Shostcall-fuel` - a broad limit which enforces that at most this  amount of data will be copied from the guest to the host in any one  API call (e.g. `string` values can&apos;t be too big, `list&lt;string&gt;` can&apos;t  be quadratic, etc). This fuel is reset on each host function call.* `-Smax-random-size` - the maximal size of the return value of the  `get-random-bytes` and `get-insecure-random-bytes` WASI functions.* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields`  values to avoid infinitely buffering data within the host.The `http` crate has additionally been updated to avoid a panic whenadding too many headers to a `fields` object.Co-authored-by: Mark Bundschuh &lt;mark@mbund.dev&gt;Co-authored-by: Pat Hickey &lt;p.hickey@f5.com&gt;Co-authored-by: Joel Dice &lt;joel.dice@akamai.com&gt;* CI fixes* Run rustfmt* Fix wasi-common build* Fix tests on 32-bit* Fix nightly test expectationsprtest:full---------Co-authored-by: Mark Bundschuh &lt;mark@mbund.dev&gt;Co-authored-by: Pat Hickey &lt;p.hickey@f5.com&gt;Co-authored-by: Joel Dice &lt;joel.dice@akamai.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Tue, 24 Feb 2026 18:23:59 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>f248b5c0 - Config knobs and validation for record-replay (#12375)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#f248b5c0</link>
        <description>Config knobs and validation for record-replay (#12375)

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Mon, 02 Feb 2026 04:30:42 +0000</pubDate>
        <dc:creator>Arjun Ramesh &lt;90422058+arjunr2@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>21797bb5 - Refactor how concurrency support is enabled in a `Store` (#12416)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#21797bb5</link>
        <description>Refactor how concurrency support is enabled in a `Store` (#12416)* Document panics from using CM async machinery when CM async is not enabled* Refactor how concurrency support is enabled in a `Store`This commit is an extension/refactor of #12377 and #12379. Notably thisdecouples the runtime behavior of Wasmtime from enabled/disabledWebAssembly proposals. This enables the `wasmtime serve` subcommand, forexample, to continue to disallow component-model-async by default butcontinue to use `*_concurrent` under the hood.Specifically a new `Config::concurrency_support` knob is added. This isplumbed directly through to `Tunables` and takes over the preexisting`component_model_concurrency` field. This field configures whethertasks/etc are enabled at runtime for component-y things. The defaultvalue of this configuration option is the same as `cfg!(feature =&quot;component-model-async&quot;)`, and this field is required ifcomponent-model-async wasm proposals are enabled. It&apos;s intended thateventually this&apos;ll affect on-by-default wasm features in Wasmtimedepending if the support is compiled in.This results in a subtle shift in behavior where component-model-asyncconcurrency is used by default now because the feature is turned on bydefault, even though the wasm features are off-by-default. This requiredadjusting a few indices expected in runtime tests due to tasks/threadsbeing allocated in index spaces.Finally, this additionally denies access at runtime to`Linker::*_concurrent` when concurrent support is disabled as otherwisethe various runtime data structures won&apos;t be initialized and panics willhappen.Closes #12393* Add a `-Wconcurrency-support` CLI flagUsed to update disas tests to show that, when disabled, old codegenquality is preserved* Ungate `Config` flag* Review comments---------Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Fri, 23 Jan 2026 22:37:55 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>caf0f752 - Minimal implementation of fixed-length lists to enable wit-bindgen runtime tests (#10619)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#caf0f752</link>
        <description>Minimal implementation of fixed-length lists to enable wit-bindgen runtime tests (#10619)* necessary parts to make the wit-bindgen test pass* post-merge fixes* fix clippy* inline type computations* link missing functionality to an issue* undo unintended removal of blank line* fix logic mistake, enable feature in wasmtime* optimized conversion* add offset* unify on name and implement wast option* cargo fmt and beautify fixed_size_list_type* add multi memory as it is needed by the test runner* standardize on the official name (component model standard) &quot;fixed-length lists&quot;changing wasm-tools (parser etc. is a different task)* More instances of fixed size corrected to fixed length

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Wed, 14 Jan 2026 16:12:38 +0000</pubDate>
        <dc:creator>Christof Petig &lt;33882057+cpetig@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>b11f8675 - Migrate CLI flags to `wasmtime::error` (#12260)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#b11f8675</link>
        <description>Migrate CLI flags to `wasmtime::error` (#12260)

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Wed, 07 Jan 2026 21:26:10 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.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/cli-flags/src/lib.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/cli-flags/src/lib.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>e06fbf70 - Cooperative Multithreading (#11751)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#e06fbf70</link>
        <description>Cooperative Multithreading (#11751)* Initial work* Almost compiling* Partially working* Cleanup* Fix merge* Cancellation and suspension refactoring* Remove printlns* Test with several threads* More testing* Cancellation* Fix cancellation for explicit suspends* Finish cancellation test* Store threads in the instance table* Deletion almost there* Tests all pass* Tighten up task deletion* Set thread state correctly* Store pairs of thread and task ids* Remove lift abi members* Cleanup unnecessary change* More cleanup* Cleanup* Revert cargo changes* Revert cargo changes* Comments* Comments on test* Update comments* Update comments* Add space that was removed in an earlier commit* Cleanup* Delete threads from the instance table* Revert cargo file* Remove dead code* Clippy changes* Clippy* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Review comments* Review feedback* Make thread IDs per-component-instance* Fix config* Tighten up completion* Clippy* Trigger full PR test* Move funcref table reading* Remove unused import* Formatting* Rename RemoveOnDrop* Review feedback* Review feedback* Move start thread closure* Review feedback* Review feedback* Correct feature for import* Review feedback* Disable failing tests* Enable fixed tests* Review feedback* Readd tests* Ignore task deletion test with Miri

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Mon, 27 Oct 2025 21:39:35 +0000</pubDate>
        <dc:creator>Sy Brand &lt;tartanllama@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>02155232 - Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#02155232</link>
        <description>Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic &quot;stack view&quot;API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The &quot;stack view&quot; performs some O(n) work when the view is initially  taken, computing some internal data per frame. This is forced by the  current design of `Backtrace`, which takes a closure and walks that  closure over stack frames eagerly (rather than work as an  iterator). It&apos;s got some impressive iterator-chain stuff going on  internally, so refactoring it to the latter approach might not  be *too* bad, but I haven&apos;t tackled it yet.  A O(1) stack view, that is, one that does work only for frames as  the host API is used to walk up the stack, is desirable because some  use-cases may want to quickly examine e.g. only the deepest  frame (say, running with a breakpoint condition that needs to read a  particular local&apos;s value after each step).- It includes a new `Config::compiler_force_inlining()` option that is  used only for testing that we get the correct frames after  inlining. I couldn&apos;t get the existing flags to work on a Wasmtime  config level and suspect there may be an existing bug there; I will  try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -&gt; native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This  prevents the current frame (`FrameView`) from walking away and hiding  somewhere it shouldn&apos;t, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate&apos;s defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing &quot;guest debugging&quot;.* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri.

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Wed, 15 Oct 2025 00:03:52 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>73de2ee9 - Pull in new regalloc2 with fastalloc fixes for exceptions, and re-enable and add to testing. (#11533)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#73de2ee9</link>
        <description>Pull in new regalloc2 with fastalloc fixes for exceptions, and re-enable and add to testing. (#11533)* Revert &quot;Cranelift/Wasmtime: disable fastalloc (single-pass) allocator for now. (#10554)&quot;This reverts commit d52e23b09191185996792b8ef18e5fca2865ca43.* Upgrade to regalloc2 0.13.1.Pulls in bytecodealliance/regalloc2#233 to update fastalloc to supportthe looser constraints needed by exception-related changes.* cargo-vet update.

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Mon, 25 Aug 2025 19:22:21 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&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/crates/cli-flags/src/lib.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/crates/cli-flags/src/lib.rs</description>
        <pubDate>Thu, 21 Aug 2025 02:55:44 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>3fab18ff - Change how wasm features/gc support work in `Config` (#11463)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#3fab18ff</link>
        <description>Change how wasm features/gc support work in `Config` (#11463)This commit aims to address #11450 in complementary but somewhatorthogonal ways. First a new `Config::gc_support` option is added whichis hooked up to the CLI as `-Wgc-support`. This option controls thewasmparser-internal `GC_TYPES` feature. Its default value, like before,is `cfg!(feature = &quot;gc&quot;)` and additionally enabling it requires the `gc`crate feature to be enabled.This commit then additionally updates how wasm features are processedduring validating a deserialized module to only require enabled featuresto be enabled in the host. Previously modules that disabled a featurebut the feature was enabled in the host would fail to deserialize. AllWebAssembly proposals are additive, however, so it&apos;s always ok todisable a feature and then load it into a module that enables the wasmproposal.Closes #11450

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Tue, 19 Aug 2025 20:48:35 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>698028ce - Add a configuration knob for `PAGEMAP_SCAN` (#11433)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#698028ce</link>
        <description>Add a configuration knob for `PAGEMAP_SCAN` (#11433)* Add a configuration knob for `PAGEMAP_SCAN`This commit adds `PoolingAlloationConfig::pagemap_scan` and additionallyadds `-Opooling-pagemap-scan` to configure on the CLI. This is the sametri-state configuration option as `MpkEnable` so that enum was renamedto just `Enabled` and repurposed for both options.This then additionally turns the option off-by-default instead of theprevious on-by-default-if-able-to to enable more slowly rolling out thisfeature.* Fix broken test

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Thu, 14 Aug 2025 22:07:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>eced7c7e - Add a new `-Sp3` option to the CLI (#11423)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#eced7c7e</link>
        <description>Add a new `-Sp3` option to the CLI (#11423)* Add a new `-Sp3` option to the CLIThis commit adds a new WASI-specific CLI option dubbed &quot;p3&quot; whichcontrols whether WASIp3 interfaces are added to the component linker andwhether WASIp3 exports are searched for. Integration here is only addedwith `wasmtime run` and support for `wasmtime serve` will come oncewasi:http is migrated to this repository from the p3-prototypingrepository.The `-Sp3` option is off-by-default at this time but this is structuredto enable it by default in the future. A test is added to ensure thatWASIp3 is usable and a basic &quot;hello world&quot; works.Some internal refactoring was done to share more code between `run` and`serve` with respect to adding WASI interfaces to a linker.* Use a normal blocking test* Fix warning

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Tue, 12 Aug 2025 23:09:23 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>3ecb338e - Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#3ecb338e</link>
        <description>Wasmtime: Add (optional) bottom-up function inlining to Wasm compilation (#11283)* Wasmtime: Add (optional) bottom-up function inlining to Wasm compilationThis commit plumbs together two pieces of recently-added infrastructure:1. function inlining in Cranelift, and2. the parallel bottom-up inlining scheduler in Wasmtime.Sprinkle some very simple inlining heuristics on top, and this gives us functioninlining in Wasm compilation.The default Wasmtime configuration does not enable inlining, and when we doenable it, we only enable it for cross-component calls by default (sincepresumably the toolchain that produced a particular core Wasm module, like LLVM,already performed any inlining that was beneficial within that module, but thattoolchain couldn&apos;t know how that Wasm module would be getting linked togetherwith other modules via component composition, and so it could not have done anycross-component inlining). For what it is worth, there is a config knob toenable intra-module function inlining, but this is primarily for use by ourfuzzers, so that they can easily excercise and explore this new inliningfunctionality.All this plumbing required some changes to the `wasmtime_environ::Compiler`trait, since Winch cannot do inlining but Cranelift can. This is mostlyencapsulated in the new `wasmtime_environ::InliningCompiler` trait, for the mostpart. Additionally, we take care not to construct the call graph, or any otherdata structures required only by the inliner and not regular compilation, bothwhen using Winch and when using Cranelift with inlining disabled.Finally, we add a `disas` test to verify that we successfully inline a series ofcalls from a function in one component, to a cross-component adapter function,to a function in another component. Most test coverage is expected to come fromour fuzzing, however.* Fix dead code warning when not `cfg(feature = &quot;component-model&quot;)`* fix winch trampoline compilation* Move CLI options to codegen* Move parameters into struct* Use an index set for call-graph construction* Smuggle inlining heuristic options through cranelift flags* Remove old CLI flags* set tunables before settings* Only configure inlining options for cranelift in fuzzing

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Tue, 29 Jul 2025 14:32:54 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>03c2a823 - Add a knob to `wasmtime::Config` and a CLI flag for GC support in the component-model (#10967)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#03c2a823</link>
        <description>Add a knob to `wasmtime::Config` and a CLI flag for GC support in the component-model (#10967)

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Fri, 06 Jun 2025 21:42:21 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>63d482c8 - Stack switching: Infrastructure and runtime support (#10388)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cli-flags/src/lib.rs#63d482c8</link>
        <description>Stack switching: Infrastructure and runtime support (#10388)* [pr1] base* prtest:full* make sure to use ControlFlow result in trace_suspended_continuation* stack-switching: cleanup: remove stray c-api changesThese are remnants of unrelated wasmfx wasmtime experiments, possiblysuitable for later submission against upstream.* stack-switching: reuse async_stack_size* stack-switching: delete delete_me debugging* stack-switching: address feedback in environ::types* stack-switching: remove unused code from vmoffsets* stack-switching: drop dependency on std* stack-switching: add compilation checks to ci matrix* stack-switching: remove debug_println cruft* stack-switching: export environ consts consistently* stack-switching: export vm pub items consistently* table_pool: reduced capacity for large elementsVMContRef elements which takes up two words and we don&apos;t want todouble the size of all tables in order to support storing these.This change changes the table to target storing the requestedmax number of elements if they are &quot;nominally&quot; sized with(potentially) reduced capacity for non-nominally sized types whenencountered.Continuations are the only type of element which may result infewer table slots being available than requested.* stack-switching: extend conditional compilationA fair bit of the definitions for stack switching are stillenabled, but this patch takes things a bit further to avoidcompilation problems; notably, cont_new is now not compiledin unless the feature is enabled.* stack-switching: formatting fixes* stack-switching: address new clippy checksIn addition, to get clippy to fully pass, plumbed inadditional config to make winch paths happy; there&apos;s noimpl for winch yet but plumbing through the feature isrequired to make paths incorporating macros at variouslayers satisfied (and it is expected we&apos;ll use thefeatures in the future).* stack-switching: more conditional compilation fixes* stack-switching: additional conditional compile on table builtins for continuations* stack-switching: additional conditional compile fixes* stack-switching: additional conditional compile in store* stack-switching: remove overly strict assertion* stack-switching: remove errantly dropped no_mangle in config c-api* stack-switching: VMContObj::from_raw_parts* stack-switching: remove duplicate async_stack_size feature check* stack-switching: VMArray -&gt; VMHostArray* stack-switching: remove unnecessary clippy exception* stack-switching: fix docs referenced VMRuntimeLimits* stack-switching: fix doc typo* stack-switching: follow recommendations for type casts* stack-switching: use usize::next_multiple_of* stack-switching: update outdated comment* stack-switching: use feature gate instead of allow(dead_code)* stack-switching: rework backtrace using chunks/zip* stack-switching: move tests to footer moduleThis is a bit more consistent with the prevailing stylein tree and (subjectively) makes finding the testsas a reader more straightforward.Tests left unchanged sans some import cleanup.* stack-swictchding: verify stack_chain offsets at runtime* fixup! stack-switching: use feature gate instead of allow(dead_code)* stack-switching: document continuation roots tracing using match arms---------Co-authored-by: Paul Osborne &lt;paul.osborne@fastly.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cli-flags/src/lib.rs</description>
        <pubDate>Wed, 04 Jun 2025 22:47:35 +0000</pubDate>
        <dc:creator>Frank Emrich &lt;git@emrich.io&gt;</dc:creator>
    </item>
</channel>
</rss>
