<?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 rooting.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>43832481 - Fix `OwnedRooted&lt;T&gt;::wasm_ty_store` missing `i31ref` check (#12451)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#43832481</link>
        <description>Fix `OwnedRooted&lt;T&gt;::wasm_ty_store` missing `i31ref` check (#12451)

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 27 Jan 2026 21:44:07 +0000</pubDate>
        <dc:creator>Zijie Zhao &lt;zijie4@illinois.edu&gt;</dc:creator>
    </item>
<item>
        <title>49ca1380 - Force callers to handle allocation failure in `Slab` (#12450)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#49ca1380</link>
        <description>Force callers to handle allocation failure in `Slab` (#12450)* Add `Vec::drain` method* Force callers to handle allocation failure in `Slab`

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 27 Jan 2026 21:41:52 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>bc4582c3 - Forbid rustdoc warnings in CI (#12420)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#bc4582c3</link>
        <description>Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 27 Jan 2026 03:47:35 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ab401d66 - Move `wasmtime-slab` crate into `wasmtime-core` (#12407)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#ab401d66</link>
        <description>Move `wasmtime-slab` crate into `wasmtime-core` (#12407)Consolidating core data structures in one location

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Fri, 23 Jan 2026 18:02:43 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ff33e949 - Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#ff33e949</link>
        <description>Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Fri, 09 Jan 2026 19:23:56 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9826719a - GC: replace ManuallyRooted with OwnedRooted. (#11514)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#9826719a</link>
        <description>GC: replace ManuallyRooted with OwnedRooted. (#11514)* GC: replace ManuallyRooted with OwnedRooted.This implements the ideas from #11445: it replaces `ManuallyRooted`,which requires an explicit unroot action with a mut borrow of the store(making it impossible to implement in a standard `Drop` impl), with`OwnedRooted`, which holds an `Arc` only to a small auxiliary memoryallocation (an `Arc&lt;()&gt;`) and uses this externalized &quot;liveness flag&quot; toallow for a `Store`-less drop. These liveness flags are scanned during a&quot;trim&quot; pass, which happens both when new owned roots are created, andjust before a GC.This should greatly increase safety for host-side users of GC: itprovides a way to have a handle whose ownership works like any otherRust value, alive until dropped. It is still not quite as efficient asLIFO-scoped handles (by analogy, for the same reason thatindividually-freed RAII types are not as efficient as arena allocation),so those remain for efficiency-minded users that have a clear picture ofreference lifetimes.At some later time we may wish to use `OwnedRooted` exclusively in ourpublic APIs rather than `Rooted`, and we may wish to rename `Rooted` to`ScopedRooted`, but I haven&apos;t done either of those things yet.I opted to *replace* `ManuallyRooted` rather than add a third kind ofroot, after discussion with fitzgen. One implication of this is that theC API&apos;s `anyref` and `externref` types are now 24 or 20 bytes ratherthan 16 (because of the `Arc` pointer), and correspondingly the Valunion grew to that size. I *believe* this is an acceptable tradeoff, butI&apos;m happy to put `ManuallyRooted` back if not.Fixes #11445.* Review feedback.* Fix for riscv32imac: loosen asserts on struct size slightly to allow for different padding.* C API: use a `*const ()` to pass the liveness-flag Arc through C.* Add some additional documentation warning about unrooting in the C API.* Fix size-of test on 32-bit platforms.* New amortized algorithm for root trimming.* core::cmp, not std::cmp* Always set high-water mark, even if eager.* Make val size-assert tolerant of padding bytes in crates/c-api/src/val.rs too.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 26 Aug 2025 18:54:25 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>8aefdcc0 - Delete `StoreOpaque::traitobj_mut` (#11444)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#8aefdcc0</link>
        <description>Delete `StoreOpaque::traitobj_mut` (#11444)* Delete `StoreOpaque::traitobj_mut`This was a fundamentally unsound function because it is widening amutable borrow to encompass more than it originally contained. Removalof its usage falls into a few buckets here:* Many instances of `store.0.traitobj_mut()` were starting from a  `&amp;mut StoreInner&lt;T&gt;`, going to `&amp;mut StoreOpaque`, then going back to  `&amp;mut dyn VMStore`. These are replaced with `store.0` as  `&amp;mut StoreInner&lt;T&gt;` directly coerces into `&amp;mut dyn VMStore`.* Some fiber-related helpers were updated to take any store-opaque-thing  which encapsulates the ability to start/resume a borrow with a part of  the store, but you only get that part of the store during the fiber  itself. This means there&apos;s no widening necessary.* Some methods previously taking `&amp;mut StoreOpaque` are now  appropriately widened to `&amp;mut dyn VMStore`.This all enables full deletion of this function which preventsaccidentally ever tripping over its unsound-ness.* Fix configured build* Another fix for a configured build* Fix a warning* Don&apos;t hold `VMStore` live over await points* Review comments* Move `AsStoreOpaque` to `store.rs` and use it in GC* Fix configured build* Switch lint annotation

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 18 Aug 2025 22:43:27 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>c6dddeaf - Minimize lazy allocation of the GC store (#11411)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#c6dddeaf</link>
        <description>Minimize lazy allocation of the GC store (#11411)* Minimize lazy allocation of the GC storeThis commit is an effort to minimize the number of entrypoints whichmight lazily allocate a GC store. The is currently done through`StoreOpaque::gc_store_mut` but this method is very commonly usedmeaning that there are many many places to audit for lazily allocating aGC store. The reason that this needs an audit is that lazy allocationis an async operation right now that must be on a fiber and is somethingI&apos;m looking to fix as part of #11262.This commit performs a few refactorings to achieve this:* `gc_store_mut` is renamed to `ensure_gc_store`. This is intended to be  an `async` function in the future and clearly demarcates where lazy  allocation of a GC store is occurring.* `require_gc_store{,_mut}` is now added which is a pure accessor of the  GC store with no lazy allocation. Most locations previously using  `gc_store_mut` are updated to use this instead.Documentation is added to store methods to clearly indicate which onesare allocating and which ones should only be called in a context whereallocation should already have happened.* Fix configured build* Relax GC store restrictions in more places* Review comments on documentation* Move `ensure_gc_store` calls during instantiationInstead update `needs_gc_heap` with the tables that are added to amodule and rely on instantiation to create the GC heap.* Shuffle around some code* Fix CI and review comments* Add in a few more i31 cases for externref

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 11 Aug 2025 20:47:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#90ac295e</link>
        <description>Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it&apos;s possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 19 May 2025 16:40:55 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>07c71ab5 - Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#07c71ab5</link>
        <description>Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functions (#10560)* Automatically trigger GC in `{Array,Extern,Struct}Ref` allocation functionsRather than forcing all callers to check for `GcHeapOutOfMemory`, trigger a GC,and then try again. This does force us to define `*_async` variations for whenasync is enabled, however; it&apos;s ultimately worth it.* cargo fmt* review feedback and fix tests* fix +runtime -gc build* more feedback and build cfg fixes* remove copy-paste assertion that doesn&apos;t apply to this method* move assertion into retry methods

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Thu, 10 Apr 2025 15:15:56 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>a4700cb7 - Analyze whether a module requires a GC heap during its compilation (#10508)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#a4700cb7</link>
        <description>Analyze whether a module requires a GC heap during its compilation (#10508)* Analyze whether a module requires a GC heap during its compilationAnd avoid forcing the allocation of a GC heap for modules that will not use it.Split out from https://github.com/bytecodealliance/wasmtime/issues/9350* Simplify condition for allocating GC heap

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Wed, 02 Apr 2025 16:18:30 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>b2e585cf - Avoid some unnecessary reduces and extends around GC libcalls (#10458)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#b2e585cf</link>
        <description>Avoid some unnecessary reduces and extends around GC libcalls (#10458)We are logically returning a `VMGcRef` from these libcalls, which is a`NonZeroU32` under the covers. We were representing that value as a `u32`, andthen to represent traps and panics, we packed that into a `u64` and if the `u64`was negative that meant there was a trap/panic but otherwise we could unpack thebottom half and that was our result.But because our GC refs are non-zero, we don&apos;t need to extend to a `u64` to geta sentinel for traps/panics; we can just use zero. That&apos;s what this commit does.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Fri, 21 Mar 2025 23:54:53 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>0a29578f - Transitively dec-ref objects in the DRC collector (#10401)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#0a29578f</link>
        <description>Transitively dec-ref objects in the DRC collector (#10401)* Transitively dec-ref objects in the DRC collectorPreviously, the DRC collector only performed shallow reference counting where ifan object&apos;s ref count was decremented and reached zero, then we would deallocatethat object, but we would not decrement the reference counts of any other objectthat was referenced by it. This commit changes that, so that now we willdecrement the reference counts of other objects referenced by an object that isbeing deallocated.This requires some method of tracing an object&apos;s outgoing edges. To avoidneeding to keep around and dispatch upon type-specific information about whichstruct fields are GC references, for example, we instead pack all GC referencesat the start of the object, just after its header. We additionally keep a countof how many GC references an object has in its header. This allows us to createa slice of any object&apos;s GC references, and we can uniformly trace any GCobject&apos;s outgoing edges. We don&apos;t need to reflect on the GC object&apos;s actualtype.A final detail: the DRC collector was previously storing the object size in thecommon GC header&apos;s reserved bits. It now stores the number of GC refs thereinstead, and the object size is stored in its own field in the DRC-specificheader, next to the ref count. This is nice because, since we are making the DRCheader larger anyways, it raises the DRC collector&apos;s implementation limit onobject size from `u27::MAX` to `u32::MAX`.Fixes #9701* update disas tests* Remove newly-added debug-assert that isn&apos;t true in certain edge casesSometimes we need to deallocate uninitialized objects when initializing theirfields fails, and this assertion trips.* fix some tests by returning an error of the correct kind of traprather than a generic anyhow error* fix tracing GC refs on big-endian architecturesWe can&apos;t cast to a slice, we need to do conversion from little-endian bytes.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 18 Mar 2025 00:50:22 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>e902e16c - Make `GcStore::expose_gc_ref_to_wasm` return the raw GC ref (#10375)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#e902e16c</link>
        <description>Make `GcStore::expose_gc_ref_to_wasm` return the raw GC ref (#10375)Every caller of `expose_gc_ref_to_wasm` except for one does this weird dancewhere they get the raw representation of the GC ref before giving up ownershipof it to the `expose_gc_ref_to_wasm` call, and then do something with the raw GCref (like return it to Wasm or whatever).This small refactoring boxes up that dance inside `expose_gc_ref_to_wasm` sothat callers don&apos;t have to do it themselves anymore. Makes things that much moreconcise and harder to mess up.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Wed, 12 Mar 2025 02:01:00 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>8818b251 - Refactor `vm::Instance` for better `Store` safety (#9565)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#8818b251</link>
        <description>Refactor `vm::Instance` for better `Store` safety (#9565)* Refactor `vm::Instance` for better `Store` safetyAt various times, for example in libcalls, we need to go from a raw `vmctx`pointer that Wasm gave us to both an `&amp;mut Instance` and an `&amp;mutStore{Opaque,Context}`. This is a pretty fundamental unsafe aspect ofimplementing a language runtimne in Rust, but we can tighten things up a bit andmake them a little safer than they currently are. This commit is such anattempt and is notably tackling the issue of creating multiple store borrowsafter we have an instance borrow.This commit makes the following changes:* `Instance` doesn&apos;t expose a method to get the raw `*mut dyn VMStore` pointer  or otherwise create a store borrow.* You cannot construct an `Instance` directly from a `vmctx` pointer.* There is now an `InstanceAndStore` type that represents unique access to both  an `Instance` and a `Store`.* You can (with `unsafe`) create an `InstanceAndStore` from a raw `vmctx`  pointer. This generally only happens inside a couple &quot;bottlenecks&quot;, not all  throughout the codebase, like the shared plumbing code for libcalls.* The `InstanceAndStore` can be unpacked into a mutable borrow of an `Instance`  and a mutable borrow of a `Store`. This unpacking takes holds a mutable borrow  of the original `InstanceAndStore`, so double borrows of the store are no  longer a concern, so long as you don&apos;t use `unsafe` to create new  `InstanceAndStore`s for the same `vmctx`.* All `Instance` methods and functions that previously would unsafely turn the  `Instance`&apos;s internal store pointer into a store borrow to perform some action  now take a store argument, and this store is threaded around as necessary.Altogether, I feel that we&apos;ve ended up with an architecture that is a safetyimprovement over where we were previously, and will help us properly avoid RustUB.For what its worth, I do not think this is the end state. I foresee at least twoadditional follow ups that I unfortunately do not currently have time for:1. Create `ComponentInstanceAndStore`, which is the same thing that this commit   did but for components. I started on this but ran out of fuel while trying to   update macros for all the component shims and transcoders.2. Stop dealing with `&amp;mut vm::Table`s and `&amp;mut vm::Global`s and all that in   the runtime. Instead just deal with indices, similar to how things are   structured in the host API level. This refactoring was not previously possible   due to (1) the `wasmtime` versus `wasmtime-runtime` crate split and (2) the lack   of `StoreOpaque`s threaded through the VM internals. The first blocker was   addressed a few months ago, this commit removes the second blocker. This will   still be a pretty large refactoring though, but I think ultimately will be worth   it.* Fix wmemcheck build* Remove `&apos;static` from the `dyn VMStore` accessors; fix no-gc build

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Tue, 05 Nov 2024 21:52:24 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>12c20b22 - Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#12c20b22</link>
        <description>Implement the Wasm GC instructions for converting between `anyref` and `externref` (#9435)* Implement the Wasm GC instructions for converting between `anyref` and `externref`This commit implements two instructions:1. `any.convert_extern`2. `extern.convert_any`These instructions are used to convert between `anyref` and `externref`values. The `any.convert_extern` instruction takes an `anyref` value andconverts it to an `externref` value. The `extern.convert_any` instruction takesan `externref` value and converts it to an `anyref` value.Rather than implementing wrapper objects -- for example an `structAnyOfExtern(ExternRef)` type that is a subtype of `AnyRef` -- we instead reusethe same representation converted references as their unconverted reference. Forexample, `(any.convert_extern my_externref)` is identical to the original`my_externref` value. This means that we don&apos;t actually emit any clifinstructions to implement these Wasm instructions; they are no-ops!Wasm code remains none-the-wiser because it cannot directly test for thedifference between, for example, a `my_anyref` and the result of`(extern.convert_any my_anyref)` because they are in two different typehierarchies, so any direct `ref.test` would be invalid. The Wasm code would haveto convert one into the other&apos;s type hierarchy, at which point it doesn&apos;t knowwhether wrapping/unwrapping took place.We did need some changes at the host API and host API implementation levels,however:* We needed to relax the requirement that a `wasmtime::AnyRef` only wraps a  `VMGcRef` that points to an object that is a subtype of `anyref` and similar for  `wasmtime::ExternRef`.* We needed to make the `wasmtime::ExternRef::data[_mut]` methods return an  option of their associated host data, since any `externref` resulting from  `(extern.convert_any ...)` does not have any associated host data. (This change  would have been required either way, even if we used wrapper objects.)* fix tests* fix wasmtime-environ tests

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Thu, 10 Oct 2024 14:41:22 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>818966f3 - Implement the `array.copy` Wasm GC instruction (#9389)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#818966f3</link>
        <description>Implement the `array.copy` Wasm GC instruction (#9389)* Implement the `array.copy` Wasm GC instructionThis also involved fixing some `VMGcRef` initialization and GC barrier code forglobals. That in turn involved making global initialization fallible, whichmeant that it needed to be pulled out of `vmctx` initialization and put intoinstance initialization.Co-Authored-By: Alex Crichton &lt;alex@alexcrichton.com&gt;* fix compile error due to code moving where a trait method was no longer in scope* use the result of `MaybeUninit::write`---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 07 Oct 2024 19:08:31 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>128e6b8f - Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#128e6b8f</link>
        <description>Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions (#9282)* Add constant evaluation support for the `struct.new[_default]` Wasm GC instructions* fix no-gc builds* wrap const evaluation in `AutoAssertNoGc`* add assertions that we access `VMGcRef`s in native-endian* fix an endian mismatch bug between compiled wasm code and host code

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Thu, 19 Sep 2024 18:05:41 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>b2025ead - Switch to new &quot;user&quot; stack maps and use `i32` for GC refs in Wasmtime (#9082)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#b2025ead</link>
        <description>Switch to new &quot;user&quot; stack maps and use `i32` for GC refs in Wasmtime (#9082)This moves Wasmtime over from the old, regalloc-based stack maps system to thenew &quot;user&quot; stack maps system.Removing the old regalloc-based stack maps system is left for follow-up work.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 19 Aug 2024 00:18:25 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>87817f38 - Improve unsupported architecture errors in Wasmtime (#9039)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs#87817f38</link>
        <description>Improve unsupported architecture errors in Wasmtime (#9039)Don&apos;t rely purely on `compile_error!` which doesn&apos;t halt compilation.Instead fill out some stubs which won&apos;t ever actually get compiled butprevent other compiler errors from cropping up.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/gc/enabled/rooting.rs</description>
        <pubDate>Mon, 29 Jul 2024 20:55:37 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
