<?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 table.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>ab78bd82 - fix: correct various typos (#12807)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.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/wasmtime/src/runtime/externals/table.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>7051ab30 - Debugging: add unique-within-store IDs for every entity. (#12645)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#7051ab30</link>
        <description>Debugging: add unique-within-store IDs for every entity. (#12645)When building an introspection API for use by a debugger, we need away to expose *identity*: that is, to give some way of knowing that agiven `Memory`, `Instance`, etc. is *this* one and not *that* one. Ourhandle types variously have either `Eq` implementations ore.g. `Module::same` for the ones that wrap an `Arc` under-the-covers;but that&apos;s not enough to allow a debugger to e.g. build a hashmap forwhatever metadata that it might expose via whatever debuggingprotocol.For maximal generality and flexibility, we should expose the uniqueIDs that already more-or-less exist: for instances, that is theirinstance ID directly; for entities owned by instances, we can build a`u64` with the instance ID in the upper 32 bits and the defined-indexin the lower 32 bits. IDs for all entities except modules areunique-within-a-Store (and this is all that is needed); IDs formodules happen to reuse the `CompiledModuleId` and so areunique-within-an-Engine.I&apos;ve opted to name these `debug_index_within_store` to scope thefeature and intended use-case clearly, but if there&apos;s a desire, Icould easily rename them to simply `index`. I shied away from thathere because I didn&apos;t want to give a notion that these indices aresomehow canonical or correspond to some order or other.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 24 Feb 2026 18:07:42 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&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/wasmtime/src/runtime/externals/table.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/wasmtime/src/runtime/externals/table.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>96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#96e19700</link>
        <description>Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Wed, 07 Jan 2026 17:08:11 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>99ecf728 - Debug: create private code memories per store when debugging is enabled.  (#12051)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#99ecf728</link>
        <description>Debug: create private code memories per store when debugging is enabled.  (#12051)* Debug: create private code memories per store when debugging is enabled.This will allow patching code to implement e.g. breakpoints. (That is,for now the copies are redundant, but soon they will not be.)This change follows the discussion [here] and offline to define a fewtypes that better encapsulate the distinction we want to enforce.Basically, there is almost never a bare `CodeMemory`; they are alwayswrapped in an `EngineCode` or `StoreCode`, the latter being a per-storeinstance of the former. Accessors are moved to the relevant place sothat, for example, one cannot get a pointer to a Wasm function&apos;s bodywithout being in the context of a `Store` where the containing modulehas been registered. The registry then returns a `ModuleWithCode` thatboxes up a `Module` reference and `StoreCode` together for cases wherewe need both the metadata from the module and the raw code to derivesomething.The only case where we return raw code pointers to the `EngineCode`directly have to do with Wasm-to-array trampolines: in some cases, e.g.`InstancePre` pre-creating data structures with references to hostfunctions, it breaks our expected performance characteristics to makethe function pointers store-specific. This is fine as long as theWasm-to-array trampolines never bake in direct calls to Wasm functions;the strong invariant is that Wasm functions never execute from`EngineCode` directly. Some parts of the component runtime would alsohave to be substantially refactored if we wanted to do away with thisexception.The per-`Store` module registry is substantially refactored in this PR.I got rid of the modules-without-code distinction (the case where amodule only has trampolines and no defined functions still works fine),and organized the BTreeMaps to key on start address rather than endaddress, which I find a little more intuitive (one then queries with thedual to the range -- 0-up-to-PC and last entry found).[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812* Review feedback: do not assume a reasonable code alignment; error when it cannot be known* Review feedback: fail properly in profiler when we are cloning code* Fix guest-profiler C API.* Review feedback: make private-code representation impossible in non-debugging-support builds.* Add TODO comment referencing issue for cloning only .text.* clang-format* Review feedback: add back Component::image_range.* Review feedback: error on registering profiling metadata when debug is enabled.* rustfmt* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Wed, 03 Dec 2025 01:18:00 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>557cc2d6 - Another batch of dependency updates (#11832)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#557cc2d6</link>
        <description>Another batch of dependency updates (#11832)* Another batch of dependency updatesBringing some deps in `Cargo.toml` up-to-date with their latest versionsalong the same lines as #11820 to avoid deps getting too stale/old.Code-wise this updates `anyhow` which enables preexisting Clippywarnings to check more code, so those warnings are fixed here as well.prtest:full* Run rustfmt

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Fri, 10 Oct 2025 17:12:23 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>155ea7fc - Remove unsoundness of widening store borrows  (#11481)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#155ea7fc</link>
        <description>Remove unsoundness of widening store borrows  (#11481)* Remove unsoundness of widening store borrowsThis commit removes preexisting unsoundness in Wasmtime where a`&amp;mut StoreOpaque` borrow was &quot;widened&quot; into encompassing the limiter onthe `T` in `StoreInner&lt;T&gt;`, for example, by using the self-pointerlocated in an instance or the store. This fix is done by threading`&amp;mut StoreOpaque` as a parameter separately from a`StoreResourceLimiter`. This means that various callers now take a new`Option&lt;&amp;mut StoreResourceLimiter&lt;&apos;_&gt;&gt;` parameter in various locations.Closes #11409* Fix gc-less build

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Thu, 21 Aug 2025 01:24:33 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>e1f50aad - Make table/memory creation async functions  (#11470)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#e1f50aad</link>
        <description>Make table/memory creation async functions  (#11470)* Make core instance allocation an `async` functionThis commit is a step in preparation for #11430, notably core instanceallocation, or `StoreOpaque::allocate_instance` is now an `async fn`.This function does not actually use the `async`-ness just yet so it&apos;s anoop from that point of view, but this propagates outwards to enoughlocations that I wanted to split this off to make future changes moredigestable.Notably some creation functions here such as making an `Instance`,`Table`, or `Memory` are refactored internally to use this new `async`function. Annotations of `assert_ready` or `one_poll` are used asappropriate as well.For reference this commit was benchmarked with our `instantiation.rs`benchmark in the pooling allocator and shows no changes relative to theoriginal baseline from before-`async`-PRs.* Make table/memory creation `async` functionsThis commit is a large-ish refactor which is made possible by the manyprevious refactorings to internals w.r.t. async-in-Wasmtime. The endgoal of this change is that table and memory allocation are both `async`functions. Achieving this, however, required some refactoring to enableit to work:* To work with `Send` neither function can close over `dyn VMStore`.  This required changing their `Option&lt;&amp;mut dyn VMStore&gt;` arugment to  `Option&lt;&amp;mut StoreResourceLimiter&lt;&apos;_&gt;&gt;`* Somehow a `StoreResourceLimiter` needed to be acquired from an  `InstanceAllocationRequest`. Previously the store was stored here as  an unsafe raw pointer, but I&apos;ve refactored this now so  `InstanceAllocationRequest` directly stores `&amp;StoreOpaque` and  `Option&lt;&amp;mut StoreResourceLimiter&gt;` meaning it&apos;s trivial to acquire  them. This additionally means no more `unsafe` access of the store  during instance allocation (yay!).* Now-redundant fields of `InstanceAllocationRequest` were removed since  they can be safely inferred from `&amp;StoreOpaque`. For example passing  around `&amp;Tunables` is now all gone.* Methods upwards from table/memory allocation to the  `InstanceAllocator` trait needed to be made `async`. This includes new  `#[async_trait]` methods for example.* `StoreOpaque::ensure_gc_store` is now an `async` function. This  internally carries a new `unsafe` block carried over from before with  the raw point passed around in `InstanceAllocationRequest`. A future  PR will delete this `unsafe` block, it&apos;s just temporary.I attempted a few times to split this PR up into separate commits buteverything is relatively intertwined here so this is the smallest&quot;atomic&quot; unit I could manage to land these changes and refactorings.* Shuffle `async-trait` dep* Fix configured build

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Thu, 21 Aug 2025 00:02:31 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>aa91737e - Relax the `Send` bound on fiber creation  (#11454)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#aa91737e</link>
        <description>Relax the `Send` bound on fiber creation  (#11454)* Relax the `Send` bound on fiber creationThis commit removes the need for `Send` for all usages of fiber-relatedbits. The goal is that the future returned from `async` functions is`Send` if all the inputs are `Send`, but there&apos;s no actual need torequire that in the function signatures themselves. This property wasidentified in upcoming work to make more internals of Wasmtime `async`where `async` functions are going to be used to implement thesynchronous path through Wasmtime where `Send` isn&apos;t a bound today, norideally do we want to have it there.The way this commit works is:* First `make_fiber` now has a `Send` bound which makes it sound. Before  #11444 it took `&amp;mut dyn VMStore` which is never `Send` and the  refactoring there missed adding this bound. This change required a few  `Send` bounds in `concurrent.rs` where it&apos;s expected to have no  impact as everything there is basically already `Send`.* Next `make_fiber_unchecked` is added which is the same as `make_fiber`  except without a `Send` bound. The `on_fiber` function is then updated  to use this `*_unchecked` variant. This means that fibers can now be  used with non-`Send` stores. Crucially though the structure of  internals in play means that future produced is still only `Send` if  `T: Send` meaning that there is no loss in safety.* Next some `Send` bounds were dropped throughout async functions in  Wasmtime as a proof-of-concept to require these changes to `on_fiber`.  This means that these entrypoints into Wasmtime no longer require  `Send`, but still naturally require `Send` if the result future is  sent to various threads.* Finally a new doctest is added to `Instance::new_async` with a  `compile_fail` example to ensure that this fails. This is  unfortunately a very brittle test because all we can assert is that  compilation failed, not why compilation failed. That means that this  is likely to regress over time, but it&apos;s the best we can do at this  time.Note that the goal here is NOT to remove `Send` bounds throughoutWasmtime. Many of them are still required, for example all the onesrelated to `Linker`. The realization is that we can remove some of the&quot;edge&quot; bounds on entrypoints where the resulting future can beconditionally `Send` depending on `T` meaning we don&apos;t actually have towrite down any bounds ourselves.This refactoring will enable future refactorings to have sync-and-asyncfunctions use the same internals and neither entrypoint needs to have a`Send` bound.* Review comments

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 19 Aug 2025 05:22:41 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>5f7cf53e - Make table growth a true `async fn` (#11442)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#5f7cf53e</link>
        <description>Make table growth a true `async fn` (#11442)* Make table growth a true `async fn`Upon further refactoring and thinking about #11430 I&apos;ve realized that wemight be able to sidestep `T: Send` on the store entirely which would bequite the boon if it can be pulled off. The realization I had is thatthe main reason for this was `&amp;mut dyn VMStore` on the stack, but thatitself is actually a bug in Wasmtime (#11178) and shouldn&apos;t be done.The functions which have this on the stack should actually ONLY have theresource limiter, if configured. This means that while the`ResourceLimiter{,Async}` traits need a `Send` supertrait that&apos;srelatively easy to add without much impact. My hunch is that plumbingthis through to the end will enable all the benefits of #11430 withoutrequiring adding `T: Send` to the store.This commit starts out on this journey by making table growth a true`async fn`. A new internal type is added to represent a store&apos;s limiterwhich is plumbed to growth functions. This represents a hierarchy ofborrows that look like:* `StoreInner&lt;T&gt;`  * `StoreResourceLimiter&lt;&apos;_&gt;`  * `StoreOpaque`    * `Pin&lt;&amp;mut Instance&gt;`      * `&amp;mut vm::Table`This notably, safely, allows operating on `vm::Table` with a`StoreResourceLimiter` at the same time. This is exactly what&apos;s neededand prevents needing to have `&amp;mut dyn VMStore`, the previous argument,on the stack.This refactoring cleans up `unsafe` blocks in table growth rightnow which manually uses raw pointers to work around the borrow checker.No more now!I&apos;ll note as well that this is just an incremental step. What I plan ondoing next is handling other locations like memory growth, memoryallocation, and table allocation. Each of those will require furtherrefactorings to ensure that things like GC are correctly accounted forso they&apos;re going to be split into separate PRs. Functionally though thisPR should have no impact other than a fiber is no longer required for`Table::grow_async`.* Remove #[cfg] gate

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Mon, 18 Aug 2025 18:03:38 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>aef5eeb5 - Refactor internals of table initialization and management (#11416)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#aef5eeb5</link>
        <description>Refactor internals of table initialization and management (#11416)* Refactor const-eval to use `Val`, not `ValRaw`This commit refactors the evaluation of constant expressions duringinstantiation for example to use `Val` instead of `ValRaw`. Previouslythe usage of `ValRaw` meant that wasm was disallowed from performing aGC during const evaluation, but currently constant expressions canindeed perform a GC. The goal of this commit is to lift this limitation.This is expected to be a minor slowdown for modules that hit this path,but most modules shouldn&apos;t hit this in a hot loop since LLVM doesn&apos;tgenerate modules that use this branch of const eval.The usage of `Val` brings a number of benefits and refactoringsassociated with it:* Const-evaluation is generally safer than before since everything is  higher-level.* GC types in const-eval were almost already using `Val` meaning that  there&apos;s actually fewer conversions now.* Instantiation code was refactored to use `wasmtime::*`-API types  instead of low-level VM types. This deduplicates a good deal and lifts  complexity out of the raw VM bits.Another issue that this commit fixes is to change how tableinitialization is modeled internally in`vm::Instance::table_init_segment`. Previously this was done by removingthe tables from an instance to get a split borrow into the store and thetable. This is not valid though because if, during initialization, a GCis performed then the table is not present to find roots through thetable. This function is refactored to scope borrows to within a loopinstead of over a loop via various refactorings and such and usage ofhigher level APIs. This is again, like above, expected to pessimizeperformance but this is also not known to be a hot path for modules atthis time.* Remove the `TableElement` typeThis commit is a refactoring of how tables work within Wasmtime to avoidfunneling table elements through a `TableElement` enum internally.Instead methods are &quot;exploded&quot; to `grow_{gc_ref,func,cont}` which means,for example, funcrefs don&apos;t need a GcStore. The main motivation for thischange was to avoid the idiom where `TableElement` represents a cloned,but unrooted, GC reference.Prior to this commit there were a number of subtle bugs in the tablecode for Wasmtime where write barriers were forgotten on `table.init`,`table.set` (via the embedder API), and `table.grow`. While `table.fill`correctly handled the GC references it was awkward to get everythingelse working consistently so I opted to remove `TableElement` entirelyto make it more clear that `&amp;VMGcRef` is ubiquitously used meaning thatthe write barriers, for example, are the same as other parts of theWasmtime codebase.This has a few extra tests for &quot;make sure this doesn&apos;t leak&quot; to ensurethat GC works correctly with new barriers in place.* Fix some lints and warnings* Fix wmemcheck build* Review comments* Optimize const eval and global initialization* Fix compile* Fix lints

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 12 Aug 2025 22:32:11 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>3e1400e7 - Tidy up `Table::copy_raw` cases (#11316)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#3e1400e7</link>
        <description>Tidy up `Table::copy_raw` cases (#11316)The `match` makes the cases a lot more clear IMO, and additionally theconditions asserted in each branch become trivially obvious (they are exactlywhat was matched upon for their associated branch) so I removed them.I also made some minor copy-edit tweaks to some comments while I was here.This would have just been a nitpick review comment onhttps://github.com/bytecodealliance/wasmtime/pull/11255 but I was traveling anddidn&apos;t get a chance to leave review comments in a reasonable amount of time, soinstead I am just fixing them up myself in this follow up.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Thu, 24 Jul 2025 17:23:37 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>f021346e - More table safety improvements (#11255)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#f021346e</link>
        <description>More table safety improvements (#11255)* More table safety improvementsThis is some more progress on #11179 aimed at improving the safety ofmanagement of tables internally within Wasmtime:* `Instance::table_index` is removed as it can be replaced with data  stored directly in the `VMTableImport` now.* `Instance::get_table` now returns `&amp;mut Table`* `Instance::get_defined_table_with_lazy_init` now returns `&amp;mut Table`* `Instance::with_defined_table_index_and_instance` now directly returns  `DefinedTableIndex` plus `Pin&lt;&amp;mut Instance&gt;`, codifying the ability  to &quot;laterally move&quot; between instances.* `Instance::table_init_segment` was refactored to &quot;take&quot; the tables  during initialization and replace them afterwards, resolving the split  borrow issue and removing an `unsafe` block in the function.cc #11179* Improve safety of `Table::copy`This commit fixes an issue in the previous commit with respect to Miriand Stacked Borrows. This does so by improving the safety of the`Table::copy`-related functions to all work mostly on safe code ratherthan unsafe references. Some minor amount of unsafety is still presentbut it is now clearly documented and easier to verify.* Fix tests

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Thu, 17 Jul 2025 17:15:13 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>ddfebe77 - Make `vm::Instance::get_defined_table_with_lazy_init` return a reference (#11215)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#ddfebe77</link>
        <description>Make `vm::Instance::get_defined_table_with_lazy_init` return a reference (#11215)This commit updates the `get_defined_table_with_lazy_init` method toreturn a safe reference instead of a raw reference. This thencascaded outwards to updating more locations to handle this new safereference as well. While this makes some further progress on #11179there are a number of locations that will require using raw pointersuntil more refactoring is done.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Wed, 16 Jul 2025 00:58:14 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>2b832281 - Gut `vm::Export` to mostly be `crate::Extern` (#11229)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#2b832281</link>
        <description>Gut `vm::Export` to mostly be `crate::Extern` (#11229)* Remove `Table::from_wasmtime_table`This commit removes the unsafe function `Table::from_wasmtime_table`.This goes a bit further and removes `ExportTable` entirely as well whichmeans that table lookup on a `vm::Instance` directly returns a`wasmtime::Table` without any need to translate back-and-forth.* Remove `Tag::from_wasmtime_tag`Like the previous commit, but for tags.* Remove `Global::from_wasmtime_global`Like the previous commit, but for globals.* Remove `Memory::from_wasmtime_memory`Like the previous commit, but for memories.* Remove `Func::from_wasmtime_function`Like previous commits, but for functions.* Fix lints* Fill out missing safety comment* Review comments

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Mon, 14 Jul 2025 21:05:01 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>838ed2d0 - Enable `allow_attributes_without_reason` (#11195)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#838ed2d0</link>
        <description>Enable `allow_attributes_without_reason` (#11195)* Enable `allow_attributes_without_reason`This commit enables the `clippy::allow_attributes_without_reason` forthe `wasmtime` crate which previously forcibly allowed it. The reasonthis was allowed was that when the workspace was first migrated theWasmtime crate had too many instances that I was willing to fix. I&apos;venow come back around and tried to fix everything.In short: ideally delete `#[allow]`, otherwise use `#[expect]`,otherwise use `#[allow]`.prtest:full* Adjust some directives* Fix some warnings* Fix stack switching size tests on unix* Don&apos;t have a conditional `Drop` impl* Force `testing_freelist` method to be usedToo lazy to write `#[cfg]`, but not too lazy to write a test.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Mon, 07 Jul 2025 21:52:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.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/wasmtime/src/runtime/externals/table.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/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Wed, 04 Jun 2025 22:47:35 +0000</pubDate>
        <dc:creator>Frank Emrich &lt;git@emrich.io&gt;</dc:creator>
    </item>
<item>
        <title>5603ee7b - Change component/instance maps to `PrimaryMap` (#10916)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#5603ee7b</link>
        <description>Change component/instance maps to `PrimaryMap` (#10916)* Change component/instance maps to `PrimaryMap`This switches to using typed keys for these maps to be more idiomaticwith the rest of Wasmtime and this has the additional benefit ofcompressing indices to 32-bits instead of the previouspointer-sized-bits.* Fix an unused import

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 03 Jun 2025 22:11:29 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>e012eeda - Remove Stored from wasmtime::Instance  (#10909)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#e012eeda</link>
        <description>Remove Stored from wasmtime::Instance  (#10909)* Remove the &quot;export cache&quot; on instancesThis is now a relic of the past now that conversion from the internalto external representation of Wasmtime items is free. This iseffectively dead code that is no longer needed.* Remove `Stored` from `wasmtime::Instance`Powered by all previous commits this is a near-trivial change where an`Instance` is now more-or-less &quot;just&quot; an `InstanceId`. Additionally the`host_state: Box&lt;dyn Any&gt;` is no longer needed within `vm::Instance` sothat was removed as well.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 03 Jun 2025 14:59:25 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>132a1a53 - Replace `as usize` with `.addr()` (#10908)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs#132a1a53</link>
        <description>Replace `as usize` with `.addr()` (#10908)Rust has since added provenance-related APIs so this is a moreintent-ful way to cast a pointer to an integer.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/runtime/externals/table.rs</description>
        <pubDate>Tue, 03 Jun 2025 14:51:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
