Changes in arrayref.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

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/vm/gc/enabled/arrayref.rs

a631d20a - cranelift: stack-switching support (#11003)

Thu, 04 Sep 2025 21:58:01 +0000

cranelift: stack-switching support (#11003)* cranelift: stack-switching supportThis initial commit represents the "pr2" base commit withminimal merge conflicts resolved. Due to OOB conflicts, thiscommit is not functional as-is, but using it as a base inorder to allow for easier reviewing of the delta fromthis commit to what will be used for the PR against upstream.Co-authored-by: Daniel Hillerström Co-authored-by: Paul Osborne * cranelift: stack-switching updates pass 1This first set of changes updates the base pr in order tocompiled and pass basic checks (compile, clippy, fmt) withthe biggest part of the change being to eliminate injectionof tracing/assertions in JIT'ed code.* cranelift: stack-switching: restore original visibility for a few func_environ members* cranelift: stack-switching conditional compilationAt this point, the only bit we really branch on is what wedo in order to avoid problems tying into wasmtime_environ.This is basd on the approach and macro used by the gc code forconverting presence/absence of the cranelift feature flag tocranelift compile time. This is a bit of a half-measure for nowas we still compile most stack-switching code in cranelift, butthis does enough to avoid causing problems with missing definitionsin wasmtime_environ.* cranelift: avoid "as" casts in stack-switchingReplace either with infallible From or fallible, panicingTryFrom alternatives where required.* cranelift: cleanup stack-switching control_effect signaturesAfter removing emission of runtime trace logging and assertions,there were several unused parameters. Remove those from theControlEffect signatures completely.* cranelift: rename stack-switching VMArray to VMHostArrayThis matches a change to the mirrored runtime type inthe upstream changes.* stack-switching: fix typoCo-authored-by: Daniel Hillerström * stack-switching: used Index impl for get_stack_slot_data* stack-switching: use smallvec over vec in several cases* stack-switching: avoid resumetable naming confusion* stack-switching: cleanup unused params from unchecked_get_continuationThe extra parameters here used to be used for emitting runtimeassertions, but with those gone we just had unused paramsand lifetimes, clean those out.* stack_switching: simplify store_data_entries assertion* stack-switching: simplify translate_table_{grow,fill} control flow* stack-switching: remove translate_resume_throw stubThere's already a stub elsewhere and this is not called, whenexceptions are added and it is time to revisit, this methodcan be restored.* stack-switching: compute control_context_size based on target triple* stack-switching: VMHostArrayRef updatesRename VMHostArray -> VMHostArrayRefChange impl to compute address with offset upfront rather thanon each load.* stack-switching: move cranelift code to live under func_environThis matches the directory structure for gc and aids in visibilityfor a few members required by stack-switching code in cranelift.* stack-switching: formatting fix* stack-switching: reduce visibility on a few additional items* stack-switching: simplify contobj fatptr con/de-struction* stack-switching: add disas tests to cover new instructions* stack-switching: fix layout of VMContObjIn the course of the various runtime updates, the layout of theruntime VMContObj got switched around. This resulted in failureswhen doing certain table operations on continuations.This change fixes that layout problem and adds some tests withoffsets to avoid the problem. Due to the way that we interactwith the VMContObj in cranelift, we don't use these offsets outsideof the tests.* Fix formatting of merge conflict resolution* cranelift: remove ir::function::get_stack_slot_dataThis method isn't required as sized_stack_slots is already pub.* stack-switching: reduce visibility of a couple func_environ methods* stack-switching: define VMContObj as two wordsThis change migrates VMContObj and its usages in cranelift and runtimeto work with the VMContObj fat pointer as two words in order to bettertarget different architectures (still gated to x86_64 for now).To support this, a size type was plumbed into the builtins functionsignature types (as is done for component types) that maps tousize.* fixup! stack-switching: define VMContObj as two words* stack-switching: add stub Val::ContRefThis type is not fully complete until continuation/gc integrationis revisited (#10248) but without these changes, test cases arenow failing on panics as we need some representation ofcontinuation references in the runtime Val enumeration.Runtime errors with TODO notes are added for the stubbedcode paths to revisit later.* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: add stub Val::ContRef* fixup! stack-switching: define VMContObj as two wordsprtest:full* stack-switching: don't conflate host and target pointer sizesDisas tests were failing on i686 targeting x86_64 as the size of thehost pointer was leaking into what we were using to do codegenin a few paths. This patch is a bit of a hack as it seems likeusing a generic for T: *mut u8 (as an example) is a bitquestionable. To keep things small, I do a hacky typecheck to mappointers to the target pointer size here.* stack-switching: VMHostArray entry sizes based off env PtrSizeRevisiting the previous commit with an approach that should beless brittle.---------Co-authored-by: Frank Emrich Co-authored-by: Daniel Hillerström List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

c6dddeaf - Minimize lazy allocation of the GC store (#11411)

Mon, 11 Aug 2025 20:47:20 +0000

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'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/vm/gc/enabled/arrayref.rs

eaa4632e - Implement exception objects. (#11230)

Tue, 15 Jul 2025 17:15:35 +0000

Implement exception objects. (#11230)* WIP: Working exception objects* Clean build with gc disabled (`cargo check -p wasmtime --no-default-features --features runtime`).* Review feedback.* Stub out C-API support.* Fix Clippy complaints.* Fix dead-code warning in c-api build.* Actually fix 27->26 reserved bit rename and test.* Fix exnref doc-test.* fix fuzzing build* fix feature-flagging on Instance::id* Bless disas test diff due to reserved-bits change.* Review feedback. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

2b832281 - Gut `vm::Export` to mostly be `crate::Extern` (#11229)

Mon, 14 Jul 2025 21:05:01 +0000

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/vm/gc/enabled/arrayref.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/vm/gc/enabled/arrayref.rs

3f530214 - Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)

Tue, 25 Mar 2025 00:38:47 +0000

Generalize `VMGcObjectDataMut` for immutable GC object accesses too (#10462)* Generalize `VMGcObjectDataMut` for immutable GC object accesses tooThis makes it generic over a `T` and then shared+immutable accesses are bound by`T: AsRef<[u8]>` and exclusive+mutable accesses are bound by `T: AsMut<[u8]>`.This allows reusing these accessors in more places in the future, and meansthere are fewer places to bounds check accesses and remember to do little-endianconversion and all that.* Make `VMGcObjectData` a fancy unsized newtype* fix no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

c52b941e - Use `NonNull` for `VMFuncRef` in more places (#9677)

Tue, 26 Nov 2024 02:59:26 +0000

Use `NonNull` for `VMFuncRef` in more places (#9677)* Use `NonNull` for `VMFuncRef` in more placesThis commit switches to using `NonNull` in more placesinstead of `*mut VMFuncRef`. A few minor locations benefitted from thisby removing some otherwise extraneous checks but most places have beenupdated to mostly do the same as before. The goal of this commit is tomake it more clear about what returns a nullable reference and whatnever returns a nullable reference. Additionally some constructors nowunconditionally work with `NonNull` instead of checking for nullinternally.* Fix a refactoring typo List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

f07c4416 - Add support for funcrefs inside GC objects (#9341)

Tue, 01 Oct 2024 16:36:42 +0000

Add support for funcrefs inside GC objects (#9341) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

ec3b2d22 - Implement most `array.*` instructions for the GC proposal (#9326)

Mon, 30 Sep 2024 19:25:35 +0000

Implement most `array.*` instructions for the GC proposal (#9326)* Implement most `array.*` instructions for the GC proposalThis does not implement `array.copy` and `array.init_elem` yet, but implementsall other `array.*` instructions:* `array.new`* `array.new_fixed`* `array.new_default`* `array.new_data`* `array.new_elem`* `array.fill`* `array.init_data`* `array.len`* `array.get`* `array.get_s`* `array.get_u`* `array.set`Note that the initial plumbing for `array.{copy,init_elem}` is in place, but theinstructions themselves are not implemented yet.* Fix no-gc builds* Fix some clippy warnings* cargo fmt* Fix another clippy error* Fix more clippy errors* Remove debug logging* Add array.fill helper* exit scope even on panic List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

9c23d884 - Split GC type layout computation into a shared trait in `wasmtime_environ` (#9246)

Fri, 13 Sep 2024 20:50:05 +0000

Split GC type layout computation into a shared trait in `wasmtime_environ` (#9246)* Split GC type layout computation into a shared trait in `wasmtime_environ`This stuff was previously living in the `GcRuntime` trait, but it turns out that thecompiler will also need to know the layout of GC types, who'd have thunk it.* Fix disabled GC builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

0bce0968 - Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)

Fri, 06 Sep 2024 22:25:50 +0000

Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)* Warn against `clippy::cast_possible_truncation` in WasmtimeThis commit explicitly enables the `clippy::cast_possible_truncation`lint in Clippy for just the `wasmtime::runtime` module. This does notenable it for the entire workspace since it's a very noisy lint and ingeneral has a low signal value. For the domain that `wasmtime::runtime`is working in, however, this is a much more useful lint. We in generalwant to be very careful about casting between `usize`, `u32`, and `u64`and the purpose of this module-targeted lint is to help with just that.I was inspired to do this after reading over #9206 where especially whenrefactoring code and changing types I think it would be useful to havelocations flagged as "truncation may happen here" which previouslyweren't truncating.The failure mode for this lint is that panics might be introduced wheretruncation is explicitly intended. Most of the time though this isn'tactually desired so the more practical consequence of this lint is toprobably slow down wasmtime ever so slightly and bloat it ever soslightly by having a few more checks in a few places. This is likelybest addressed in a more comprehensive manner, however, rather thanspecifically for just this one case. This problem isn't unique to justcasts, but to many other forms of `.unwrap()` for example.* Fix some casts in tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs

c4be2d84 - Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)

Tue, 20 Aug 2024 19:34:28 +0000

Introduce `wasmtime::ArrayRef` and allocating Wasm GC arrays (#9145)* Introduce `wasmtime::ArrayRef` and allocating Wasm GC arraysThis commit introduces the `wasmtime::ArrayRef` type and support for allocatingWasm GC arrays from the host. This commit does *not* add support for the`array.new` family of Wasm instructions; guests still cannot allocate Wasm GCobjects yet, but initial support should be pretty straightforward after thiscommit lands.The `ArrayRef` type has everything you expect from other value types in the`wasmtime` crate:* A method to get its type or check whether it matches a given type* An implementation of `WasmTy` so that it can be used with `Func::wrap`-style APIs* The ability to upcast it into an `AnyRef` and to do checked downcasts in the opposite directionThere are, additionally, methods for getting, setting, and enumerating a`ArrayRef`'s elements.Similar to how allocating a Wasm GC struct requires a `StructRefPre`, allocatinga Wasm GC array requires an `ArrayRefPre`, and this is motivated by the samereasons.* fix some doc tests and add docs for Func::wrap-style APIs* Add a comment about why we can't user `iter::repeat(elem).take(len)`* Fix some warnings in no-gc builds List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/gc/enabled/arrayref.rs