Changes in resources.rs

c14dd11b - Add a new `ResourceDynamic` type (#11885)

Mon, 20 Oct 2025 17:21:50 +0000

Add a new `ResourceDynamic` type (#11885)* Move `ResourceAny` to its own submoduleIn preparation for upcoming other refactorings...* Move `Resource` to its own submodule* Move `ResourceType` to its own submodule* Move host resource table infrastructure to its own module* Add module documentation to resource-related modules* Add a new `ResourceDynamic` typeThis commit adds a new type `wasmtime::component::ResourceDynamic` tothe embedding API which internally is more-or-less the same as`Resource` but with different type information. This`ResourceDynamic` specifically enables storing runtime information formanaging the type of the resource as opposed to `Resource` whichrequires static information.The main goal of this type is to enable exposing resources in the C APIof Wasmtime. Currently there is no way to define different resourcetypes in the C API because the only option is `Resource`. With thistype it will be possible to create distinct resource types in the C APIfor embedders to use.cc #11437* Apply suggestions from code reviewCo-authored-by: Joel Dice ---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

8fbe4c2c - Fix some panics compiling components and resources (#11798)

Mon, 06 Oct 2025 22:36:55 +0000

Fix some panics compiling components and resources (#11798)In working on bytecodealliance/wasm-tools#2335 I found that there's afew test cases in wasm-tools which Wasmtime was panicking to compile.The issues were all related to resource types and how information wasn'tregistered ahead of time before it was translated from wasmparser'srepresentation to Wasmtime's representation. The high-level cause forthis had to do with how component and instance types are handled, asopposed to concrete components or instances themselves. This waseffectively a hole in Wasmtime's translation process for componentswhich has never been filled out since the original implementation ofresources. The reason that this never came up before is:* Most components don't currently import or export a component itself.* Most components don't currently import or export component or instance types (as opposed to values).One of these was required to trigger this issue. The solutionimplemented in this commit is to plumb the concept of an "abstractresource" which is part of a type but not actually ever used at runtimeexcept for type equality during type reflection. This is expected tohave little-to-no impact on real-world components given that thesesituations are rarely occurring. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

7dba8efd - Rename `Lift` and `Lower` trait methods (#11070)

Fri, 20 Jun 2025 18:52:21 +0000

Rename `Lift` and `Lower` trait methods (#11070)* `Lower::lower` becomes `Lower::linear_lower_to_flat`* `Lower::store` becomes `Lower::linear_lower_to_memory`* `Lift::lift` becomes `Lift::linear_lift_from_flat`* `Lift::load` becomes `Lift::linear_lift_from_memory`This renaming is to distinguish these linear-memory methods from the GC versionsthat will be added in follow up commits.No functional changes here, just renaming. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it'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/component/resources.rs

f81c0dc0 - Add `T: 'static` to `Store` (#10760)

Tue, 13 May 2025 05:08:32 +0000

Add `T: 'static` to `Store` (#10760)* Add `T: 'static` to `StoreSince the beginning the `T` type parameter on `Store` has had nobounds on it. This was intended for maximal flexibility in terms of whatembedders place within a `Store` and I've personally advocated thatwe need to keep it this way. In the development of the WASIp3 work,however, I've at least personally reached the conclusion that this is nolonger tenable and proceeding will require adding a `'static` bound todata within a store.Wasmtime today [already] carries unsafe `transmute`s to work around thislack of `'static` bound, and while the number of `unsafe` parts isrelatively small right now we're still fundamentally lying to thecompiler about lifetime bounds internally. With the WASIp3 async workthis degree of "lying" has become even worse. Joel has written up someexamples [on Zulip] about how the Rust compiler is requiring `'static`bounds in surprising ways. These patterns are cropping up quitefrequently in the WASIp3 work and it's becoming particularly onerousmaintaining all of the `unsafe` and ensuring that everything is in sync.In the WASIp3 repository I've additionally [prototyped a change] whichwould additionally practically require `T: 'static` in more locations.This change is one I plan on landing in Wasmtime in the near future andwhile its main motivations are for enabling WASIp3 work it is also amuch nicer system than what we have today, in my opinion.Overall the cost of not having `T: 'static` on `Store` is effectivelybecoming quite costly, in particular with respect to WASIp3 work. Thisis coupled with all known embedders already using `T: 'static` datawithin a `Store` so the expectation of the impact of this change isnot large. The main downside of this change as a result is that when andwhere to place `'static` bounds is sort of a game of whack-a-mole withthe compiler. For example I changed `Store` to require `'static`here, but the rest of the change is basically "hit compile until rustcsays it's ok". There's not necessarily a huge amount of rhyme-or-reasonto where `'static` bounds crop up, which can be surprising or difficultto work with for users.In the end I feel that this change is necessary and one we can't shyaway from. If problems crop up we'll need to figure out how to threadthat needle at that time, but I'm coming around to thinking that`T: 'static` is just a fundamental constraint we'll have to take on atthis time. Maybe a future version of Rust that fixes some of Joel'sexamples (if they can be fixed, we're not sure of that) we couldconsider relaxing this but that's left for future work.[already]: https://github.com/bytecodealliance/wasmtime/blob/35053d6d8d1a5d4692cf636cba0c920b4a79a44b/crates/wasmtime/src/runtime/store.rs#L602-L611[on Zulip]: https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.22type.20may.20not.20live.20long.20enough.22.20for.20generic.20closure/near/473862072[prototyped a change]: https://github.com/bytecodealliance/wasip3-prototyping/pull/158* Remove a no-longer-necessary `unsafe` block* Update test expectations* Fix gc-disabled builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

28e26fdf - Collapse resource tables to be per-instance, not per-resource (#10701)

Wed, 30 Apr 2025 22:09:45 +0000

Collapse resource tables to be per-instance, not per-resource (#10701)This commit is an update to how Wasmtime represents and processesresource handles for components. The upstream specification changed inWebAssembly/component-model#427 and while it's been awhile since thatchange this is Wasmtime catching up to that change. It's expected thatthese paths are going to get stressed more with component model asyncand more kinds of handles so this additionally refactors things to leavesort of "holes" where async resources are going to go.This notably will result in different behavior for guest programs.Previously if there were two resources imported into a guest they couldhave overlapping indices and now they're going to all have disjointindices since they're all in the same index space. It's expected thatthis is will have a minimal, if any, impact on component guests as intheory they're all mostly treating handles as opaque indexes todayanyway. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

10eda1cf - Support platforms without 64-bit atomics (#10134)

Wed, 29 Jan 2025 15:53:25 +0000

Support platforms without 64-bit atomics (#10134)* Support platforms without 64-bit atomicsThis commit enables Wasmtime to build on platforms without 64-bit atomicinstructions, such as Rust's `riscv32imac-unknown-none-elf` target.There are only two users of 64-bit atomics right now which are epochsand allocation of `StoreId`. This commit adds `#[cfg]` to epoch-relatedinfrastructure in the runtime to turn that all of if 64-bit atomicsaren't available. The thinking is that epochs more-or-less don't workwithout 64-bit atomics so it's easier to just remove them entirely.Allocation of `StoreId` is trickier though because it's so core toWasmtime and it basically can't be removed. I've opted to change theallocator to 32-bit indices instead of 64-bit indices. Note that`StoreId` requires unique IDs to be allocated for safety which meansthat while a 64-bit integer won't overflow for a few thousand years a32-bit integer will overflow in a few hours from quickly creatingstores. The rough hope though is that embeddings on platforms like thisaren't churning through stores. Regardless if this condition istriggered it'll result in a panic rather than unsoundness, so wehopefully have at least that going for us.Closes #8768* Update component resources to not use `AtomicU64`These aren't intended to be used in threaded contexts anyway and the useof `AtomicXXX` is just to have interior mutability while still being`Send` and `Sync`. Switch to using `AtomicU32` which is more portable.* Use `RwLock` for `StoreId` instead.* Fix compile* Fix imports List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

b86b9682 - Provenance preparation for Pulley (#10043)

Thu, 23 Jan 2025 20:55:28 +0000

Provenance preparation for Pulley (#10043)* Provenance preparation for PulleyThis commit is an internal refactoring of Wasmtime's runtime to prepareto execute Pulley in MIRI. Currently today this is not possible becausePulley does not properly respect either strict or permissive provenancemodels. The goal of this refactoring is to enable fixing this in afuture commit that doesn't touch everything in the codebase. Insteadeverything is touched here in this commit.The basic problem with Pulley is that it is incompatible with the strictprovenance model of Rust which means that we'll be using "exposedprovenance" APIs to satisfy Rust's soundness requirements. In this modelwe must explicitly call `ptr.expose_provenance()` on any pointerswhich are exposed to compiled code. Arguably we should also be alreadydoing this for natively-compiled code but I am not certain about howstrictly this is required.Currently in Wasmtime today we call `ptr.expose_provenance()` nowhere.It also turns out, though, that we share quite a few pointers in quite afew places with compiled code. This creates a bit of a problem! Thesolution settled on in this commit looks like:* A new marker trait, `VmSafe`, is introduced. This trait is used to represent "safe to share with compiled code" types and enumerates some properties such as defined ABIs, primitives wrappers match primitive ABIs, and notably "does not contain a pointer".* A new type, `VmPtr`, is added to represent pointers shared with compiled code. Internally for now this is just `SendSyncPtr` but in the future it will be `usize`. By using `SendSyncPtr` it shouldn't actually really change anything today other than requiring a lot of refactoring to get the types to line up.* The core `vmctx_plus_offset*` methods are updated to require `T: VmSafe`. Previously they allowed any `T` which is relatively dangerous to store any possible Rust type in Cranelift-accessible areas.These three fundamental changes were introduced in this commit. Allfurther changes were refactoring necessary to get everything workingafter these changes. For example many types in `vmcontext.rs`, such as`VMFuncRef`, have changed to using `VmPtr` instead of `NonNull` or`*mut T`. This is a pretty expansive change which resulted in touching alot of places.One premise of `VmPtr` is that it's non-null. This was anadditional refactoring that updated a lot of places where previously`*mut T` was used and now either `VmPtr` or `NonNull` is used.In the end the intention is that `VmPtr` is used whenever pointersare store in memory that can be accessed from Cranelift. When operatinginside of the runtime `NonNull` or `SendSyncPtr` is preferredinstead.As a final note, no provenance changes have actually happened yet. Forexample this doesn't fix Pulley in MIRI. What it does enable, though, isthat the future commit to fix Pulley in MIRI will be much smaller withthis having already landed.* Run the full test suite in PR CIprtest:full* Minor CI issues* Fix no_std build* Fix miri build* Don't use `VmPtr` in FFI function signaturesUse `NonNull` or `*mut u8` as appropriate for function signaturesinstead. It shouldn't be required to use `VmPtr` during the handoff tocompiled code as we've already annotated the pointer going out.* Fix rebase conflict* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

43ebcb89 - Remove usage of `gen` as an identifier (#9958)

Thu, 09 Jan 2025 16:47:51 +0000

Remove usage of `gen` as an identifier (#9958)This commit is a start to some preparation for the Rust 2024 edition forWasmtime and this workspace. The `rust-2024-compatibility` lint group inrustc, currently off-by-default, is intended to assist with migratingcode to prepare for the 2024 edition. Some of those lints though are, inmy opinion, far too noisy to be turned on so this PR doesn't turn on thewhole group. Instead though I plan on enabling individual lints overtime in our `Cargo.toml` before the 2024 edition is enabled. This shouldhopefully provide a relatively smooth and less churn-y path to enablingthe 2024 edition in the future.The first lint enabled here in this commit is the `keyword_idents_2024`lint which warns against usage of identifiers that will become keywordsin the 2024 edition. The only one affecting Wasmtime is the `gen`identifier (soon to be keyword) and we had quite a few instances of it.Where possible I've renamed to `generator` or `generate` or `generated`but when used as methods from upstream crate traits (e.g.`RngCore::gen`) we're forced to use `r#gen`. The `rand` crate will beupdated in 0.9.0 to avoid this keyword so this shouldn't be permanent. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

8995bcc4 - Use a helper method to invoke `VMFuncRef::array_call` (#9630)

Wed, 20 Nov 2024 18:34:09 +0000

Use a helper method to invoke `VMFuncRef::array_call` (#9630)* Use a helper method to invoke `VMFuncRef::array_call`This is intended to encapsulate the usage of a native raw pointer and inthe future act as a dispatch point for invoking Pulley instead of nativecode.* Fix some callers* More fixese List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

d6713c50 - Update nightly in CI to latest (#9195)

Tue, 03 Sep 2024 17:31:50 +0000

Update nightly in CI to latest (#9195)Additionally address some new warnings that are cropping up throughoutthe codebase. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

Fri, 14 Jun 2024 15:24:12 +0000

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

964f8986 - Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)

Fri, 03 May 2024 16:01:12 +0000

Use rustdoc's `doc_auto_cfg` feature instead of `doc_cfg` (#8532)This commit removes all our `#[cfg_attr(..., doc(cfg(...)))]`annotations throughout Wasmtime and `wasmtime-wasi`. These are allreplaced with `feature(doc_auto_cfg)` which automatically infers theattribute to show rather than requiring us to duplicate it.Spot-checking the docs this looks just-as-readable while being mucheasier to maintain over time. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

72004aad - Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

Tue, 30 Apr 2024 18:52:45 +0000

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`* Remove dep on `wasmtime-runtime` from `wasmtime-cli`* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module* Update labeler for merged crates* Fix `publish verify`prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

dce7b777 - Clear borrow tracking converting `ResourceAny` to `Resource` (#8071)

Fri, 08 Mar 2024 23:46:20 +0000

Clear borrow tracking converting `ResourceAny` to `Resource` (#8071)This commit clears out the dynamic tracking of borrows within a`ResourceAny` when it's converted to a `Resource`. The `Resource`type doesn't participate in this borrow tracking in the same way as`ResourceAny` because it's assumed that hosts are well-behaved in thisregard. This means that the conversion here should respect theseguarantees of `Resource` and auto-clear the borrow tracking. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

dd3f8d8b - Move dtor information from `ResourceAny` into a `Store` (#8061)

Fri, 08 Mar 2024 16:08:54 +0000

Move dtor information from `ResourceAny` into a `Store` (#8061)* Move dtor information from `ResourceAny` into a `Store`This commit moves the internals of the `ResourceAny` type related todestructors into the auxiliary data within a `Store`. This avoids theneed to carry around pointers with `ResourceAny` and additionally makesit easier to work with.As part of this commit this also updates the behavior of`ResourceAny::try_from_resource` to no longer need an `InstancePre` andtype information. This was required originally to get`ResourceAny::resource_drop` working to drop the host resource. Inretrospect I'm not sure if this was the best goal to achieve because`Resource` already has no destructor support and one of the morecommon use cases for the conversion is to simply turn around and give itback to a component where a component already has enough destructorinformation.In the end this should make both `ResourceAny` and `Resource` prettyclose to "just an index" which is easier to reason about when workingwith resources than carrying additional pointers.* Remove now-unneeded ResourceImportIndex machinery List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

7dc12f2b - Fix a panic reflecting the types of a component (#8031)

Thu, 29 Feb 2024 18:49:41 +0000

Fix a panic reflecting the types of a component (#8031)This commit fixes an issue when inspecting the types of a componentwhere if a resource type wasn't substituted through an import it wouldend up panicking. The fix here is to add a third kind of resource typewhich represents an uninstantiated component as opposed to aninstantiated component or host type.Closes #8003 List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

93f17e3c - Reserve handle index 0 in the component model (#7661)

Wed, 21 Feb 2024 18:07:10 +0000

Reserve handle index 0 in the component model (#7661)This commit updates the allocation scheme for resources in the componentmodel to start at 1 instead of 0 when communicating with components.This is an implementation of WebAssembly/component-model#284.While this broke a number of tests we have this shouldn't actually breakany components in practice. The broken tests were all overly-precise intheir assertions and error messages and this shouldn't idiomaticallycome up in any guest language, so this should not be a practicallybreaking change.This change additionally places an upper limit on the maximumallocatable index at `1 << 30` which is also specified in the above PR. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs

4691f69e - Perform stronger typechecks of host-owned resources (#7902)

Mon, 12 Feb 2024 22:32:39 +0000

Perform stronger typechecks of host-owned resources (#7902)* Perform stronger typechecks of host-owned resourcesRight now the abstraction for host-owned resources in Wasmtime is quitesimple, it's "just an index". This can be error prone because the hostcan suffer both from use-after-free and ABA-style problems. Whilethere's not much that can be done about use-after-free the previousimplementation would accidentally enable "AB" style problems where if ahost-owned resource index was deallocated and then reallocated withanother type the original handle would still work. While not a major bugthis can be confusing and additionally violate's our guarantees as acomponent runtime to guests to ensure that resources always have valid`rep`s going into components.This commit adds a new layer of storage which keeps track of the`ResourceType` for all host-owned resources. This means that resourcesgoing into a host-owned table now record their type and coming out of ahost-owned table a typecheck is always performed. Note that guests cancontinue to skip this logic as they already have per-type tables and sowon't suffer the same issue.This change is inspired by my taking a look at #7883. The crux of theissue was a typo where a resource was reused by accident which led toconfusing behavior due to the reuse. This change instead makes it returnan error more quickly and doesn't allow the component to see any invalidstate.Closes #7883* Fix test* Use generation counters, not types* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/resources.rs