Changes in funcref.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/funcref.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/tests/all/funcref.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/tests/all/funcref.rs

ff93bce0 - Wasmtime: Finish support for the typed function references proposal (#7943)

Tue, 20 Feb 2024 20:33:28 +0000

Wasmtime: Finish support for the typed function references proposal (#7943)* Wasmtime: Finish support for the typed function references proposalWhile we supported the function references proposal inside Wasm, we didn'tsupport it on the "outside" in the Wasmtime embedder APIs. So much of the workhere is exposing typed function references, and their type system updates, inthe embedder API. These changes include:* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the introduction of the `RefType` and `HeapType` types and a `ValType::Ref(RefType)` variant.* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead there are `ValType::matches` and `FuncType::matches` methods which check directional subtyping. I also added `ValType::eq` and `FuncType::eq` static methods for the rare case where someone needs to check precise equality, but that is almost never actually the case, 99.99% of the time you want to check subtyping.* There are also public `Val::matches_ty` predicates for checking if a value is an instance of a type, as well as internal helpers like `Val::ensure_matches_ty` that return a formatted error if the value does not match the given type. These helpers are used throughout Wasmtime internals now.* There is now a dedicated `wasmtime::Ref` type that represents reference values. Table operations have been updated to take and return `Ref`s rather than `Val`s.Furthermore, this commit also includes type registry changes to correctly managelifetimes of types that reference other types. This wasn't previously an issuebecause the only thing that could reference types that reference other types wasa Wasm module that added all the types that could reference each other at thesame time and removed them all at the same time. But now that the previouslydiscussed work to expose these things in the embedder API is done, type lifetimemanagement in the registry becomes a little trickier because the embedder mightgrab a reference to a type that references another type, and then unload theWasm module that originally defined that type, but then the user should still beable use that type and the other types it transtively references. Before, wewere refcounting individual registry entries. Now, we still are refcountingindividual entries, but now we are also accounting for type-to-type referencesand adding a new type to the registry will increment the refcounts of each ofthe types that it references, and removing a type from the registry willdecrement the refcounts of each of the types it references, and then recursively(logically, not literally) remove any types whose refcount has now reached zero.Additionally, this PR adds support for subtyping to `Func::typed`- and`Func::wrap`-style APIs. For result types, you can always use a supertype of theWebAssembly function's actual declared return type in `Func::typed`. And forparam types, you can always use a subtype of the Wasm function's actual declaredparam type. Doing these things essentially erases information but is alwayscorrect. But additionally, for functions which take a reference to a concretetype as a parameter, you can also use the concrete type's supertype. Consider aWebAssembly function that takes a reference to a function with a concrete type:`(ref null )`. In this scenario, there is no static`wasmtime::Foo` Rust type that corresponds to that particular Wasm-definedconcrete reference type because Wasm modules are loaded dynamically atruntime. You *could* do `f.typed::, ()>()`, and while that iscorrectly typed and valid, it is often overly restrictive. The only value youcould call the resulting typed function with is the null function reference, butwe'd like to call it with non-null function references that happen to be of thecorrect type. Therefore, `f.typed, ()>()` is also allowed in thiscase, even though `Option` represents `(ref null func)` which is thesupertype, not subtype, of `(ref null )`. This does imply someminimal dynamic type checks in this case, but it is supported for betterergonomics, to enable passing non-null references into the function.We can investigate whether it is possible to use generic type parameters andcombinators to define Rust types that precisely match concrete reference typesin future, follow-up pull requests. But for now, we've made things usable, atleast.Finally, this also takes the first baby step towards adding support for the WasmGC proposal. Right now the only thing that is supported is `nofunc` references,and this was mainly to make testing function reference subtyping easier. Butthat does mean that supporting `nofunc` references entailed also adding a`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So weofficially have an in-progress implementation of Wasm GC in Wasmtime after thisPR lands!Fixes https://github.com/bytecodealliance/wasmtime/issues/6455* Fix WAT in test to be valid* Check that dependent features are enabled for function-references and GC* Remove unnecessary engine parameters from a few methodsEver since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,we don't need these anymore.Still useful to keep the `Engine` parameter around for the `ensure_matches`methods because that can be used to check correct store/engine usage forembedders.* Add missing dependent feature enabling for some tests* Remove copy-paste bit from test* match self to show it is uninhabited* Add a missing `is_v128` method* Short circuit a few func type comparisons* Turn comment into part of doc comment* Add test for `Global::new` and subtyping* Add tests for embedder API, tables, and subtyping* Add an embedder API test for setting globals and subtyping* Construct realloc's type from its index, rather than from scratch* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`* Fix call benchmark compilation* Change `WasmParams::into_abi` to take the whole func type instead of iter of params* Fix doc linksprtest:full* Fix size assertion on s390x List of files: /wasmtime-44.0.1/tests/all/funcref.rs

8652011f - Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)

Fri, 09 Feb 2024 21:07:52 +0000

Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)* Refactor `wasmtime::FuncType` to hold a handle to its registered typeRather than holding a copy of the type directly, it now holds a `RegisteredType`which internally is* A `VMSharedTypeIndex` pointing into the engine's types registry.* An `Arc` handle to the engine's type registry.* An `Arc` handle to the actual type.The last exists only to keep it so that accessing a `wasmtime::FuncType`'sparameters and results fast, avoiding any new locking on call hot paths.This is helping set the stage for further types and `TypeRegistry` refactorsneeded for Wasm GC.* Update the C API for the function types refactorprtest:full* rustfmt* Fix benches build List of files: /wasmtime-44.0.1/tests/all/funcref.rs

7f0228c9 - Fix some warnings on nightly Rust (#6388)

Tue, 16 May 2023 20:54:20 +0000

Fix some warnings on nightly Rust (#6388)Upstream rust has decided that ignoring a value is not spelled`drop(foo)` but instead it's spelled `let _ = foo` List of files: /wasmtime-44.0.1/tests/all/funcref.rs

c0bb341d - Run some tests in MIRI on CI (#6332)

Wed, 03 May 2023 21:02:33 +0000

Run some tests in MIRI on CI (#6332)* Run some tests in MIRI on CIThis commit is an implementation of getting at least chunks of Wasmtimeto run in MIRI on CI. The full test suite is not possible to run in MIRIbecause MIRI cannot run Cranelift-produced code at runtime (aka itdoesn't support JITs). Running MIRI, however, is still quite valuable ifwe can manage it because it would have trivially detectedGHSA-ch89-5g45-qwc7, our most recent security advisory. The goal of thisPR is to select a subset of the test suite to execute in CI under MIRIand boost our confidence in the copious amount of `unsafe` code inWasmtime's runtime.Under MIRI's default settings, which is to use the [StackedBorrows][stacked] model, much of the code in `Instance` and `VMContext`is considered invalid. Under the optional [Tree Borrows][tree] model,however, this same code is accepted. After some [extremely helpfuldiscussion][discuss] on the Rust Zulip my current conclusion is thatwhat we're doing is not fundamentally un-sound but we need to model itin a different way. This PR, however, uses the Tree Borrows model forMIRI to get something onto CI sooner rather than later, and I hope tofollow this up with something that passed Stacked Borrows. Additionallythat'll hopefully make this diff smaller and easier to digest.Given all that, the end result of this PR is to get 131 separate unittests executing on CI. These unit tests largely exercise the embeddingAPI where wasm function compilation is not involved. Some tests compilewasm functions but don't run them, but compiling wasm through Craneliftin MIRI is so slow that it doesn't seem worth it at this time. This doesmean that there's a pretty big hole in MIRI's test coverage, but that'sto be expected as we're a JIT compiler after all.To get tests working in MIRI this PR uses a number of strategies:* When platform-specific code is involved there's now `#[cfg(miri)]` for MIRI's version. For example there's a custom-built "mmap" just for MIRI now. Many of these are simple noops, some are `unimplemented!()` as they shouldn't be reached, and some are slightly nontrivial implementations such as mmaps and trap handling (for native-to-native function calls).* Many test modules are simply excluded via `#![cfg(not(miri))]` at the top of the file. This excludes the entire module's worth of tests from MIRI. Other modules have `#[cfg_attr(miri, ignore)]` annotations to ignore tests by default on MIRI. The latter form is used in modules where some tests work and some don't. This means that all future test additions will need to be effectively annotated whether they work in MIRI or not. My hope though is that there's enough precedent in the test suite of what to do to not cause too much burden.* A number of locations are fixed with respect to MIRI's analysis. For example `ComponentInstance`, the component equivalent of `wasmtime_runtime::Instance`, was actually left out from the fix for the CVE by accident. MIRI dutifully highlighted the issues here and I've fixed them locally. Some locations fixed for MIRI are changed to something that looks similar but is subtly different. For example retaining items in a `Store` is now done with a Wasmtime-specific `StoreBox` type. This is because, with MIRI's analyses, moving a `Box` invalidates all pointers derived from this `Box`. We don't want these semantics, so we effectively have a custom `Box` to suit our needs in this regard.* Some default configuration is different under MIRI. For example most linear memories are dynamic with no guards and no space reserved for growth. Settings such as parallel compilation are disabled. These are applied to make MIRI "work by default" in more places ideally. Some tests which perform N iterations of something perform fewer iterations on MIRI to not take quite so long.This PR is not intended to be a one-and-done-we-never-look-at-it-againkind of thing. Instead this is intended to lay the groundwork tocontinuously run MIRI in CI to catch any soundness issues. This feels,to me, overdue given the amount of `unsafe` code inside of Wasmtime. Myhope is that over time we can figure out how to run Wasm in MIRI butthat may take quite some time. Regardless this will be adding nontrivialmaintenance work to contributors to Wasmtime. MIRI will be run on CI formerges, MIRI will have test failures when everything else passes,MIRI's errors will need to be deciphered by those who have probablynever run MIRI before, things like that. Despite all this to me it seemsworth the cost at this time. Just getting this running caught twopossible soundness bugs in the component implementation that could havehad a real-world impact in the future![stacked]: https://github.com/rust-lang/unsafe-code-guidelines/blob/master/wip/stacked-borrows.md[tree]: https://perso.crans.org/vanille/treebor/[discuss]: https://rust-lang.zulipchat.com/#narrow/stream/269128-miri/topic/Tree.20vs.20Stacked.20Borrows.20.26.20a.20debugging.20question* Update alignment comment List of files: /wasmtime-44.0.1/tests/all/funcref.rs

666c2554 - Merge pull request from GHSA-gwc9-348x-qwv2

Thu, 31 Mar 2022 21:26:01 +0000

Merge pull request from GHSA-gwc9-348x-qwv2* Run the GC smoketest with epoch support enabled as well.* Handle safepoints in cold blocks properly.Currently, the way that we find safepoint slots for a given instructionrelies on the instruction index order in the safepoint list matching theorder of instruction emission.Previous to the introduction of cold-block support, this was triviallysatisfied by sorting the safepoint list: we emit instructions 0, 1, 2,3, 4, ..., and so if we have safepoints at instructions 1 and 4, we willencounter them in that order.However, cold blocks are supported by swizzling the emission order atthe last moment (to avoid having to renumber instructions partwaythrough the compilation pipeline), so we actually emit instructions outof index order when cold blocks are present.Reference-type support in Wasm in particular uses cold blocks forslowpaths, and has live refs and safepoints in these slowpaths, so wecan reliably "skip" a safepoint (not emit any metadata for it) in thepresence of reftype usage.This PR fixes the emission code by building a map from instruction indexto safepoint index first, then doing lookups through this map, ratherthan following along in-order as it emits instructions. List of files: /wasmtime-44.0.1/tests/all/funcref.rs

bcf35449 - Optimize `Func::call` and its C API (#3319)

Tue, 21 Sep 2021 19:07:05 +0000

Optimize `Func::call` and its C API (#3319)* Optimize `Func::call` and its C API This commit is an alternative to #3298 which achieves effectively the same goal of optimizing the `Func::call` API as well as its C API sibling of `wasmtime_func_call`. The strategy taken here is different than #3298 though where a new API isn't created, rather a small tweak to an existing API is done. Specifically this commit handles the major sources of slowness with `Func::call` with: * Looking up the type of a function, to typecheck the arguments with and use to guide how the results should be loaded, no longer hits the rwlock in the `Engine` but instead each `Func` contains its own `FuncType`. This can be an unnecessary allocation for funcs not used with `Func::call`, so this is a downside of this implementation relative to #3298. A mitigating factor, though, is that instance exports are loaded lazily into the `Store` and in theory not too many funcs are active in the store as `Func` objects. * Temporary storage is amortized with a long-lived `Vec` in the `Store` rather than allocating a new vector on each call. This is basically the same strategy as #3294 only applied to different types in different places. Specifically `wasmtime::Store` now retains a `Vec` for `Func::call`, and the C API retains a `Vec` for calling `Func::call`. * Finally, an API breaking change is made to `Func::call` and its type signature (as well as `Func::call_async`). Instead of returning `Box<[Val]>` as it did before this function now takes a `results: &mut [Val]` parameter. This allows the caller to manage the allocation and we can amortize-remove it in `wasmtime_func_call` by using space after the parameters in the `Vec` we're passing in. This change is naturally a breaking change and we'll want to consider it carefully, but mitigating factors are that most embeddings are likely using `TypedFunc::call` instead and this signature taking a mutable slice better aligns with `Func::new` which receives a mutable slice for the results. Overall this change, in the benchmark of "call a nop function from the C API" is not quite as good as #3298. It's still a bit slower, on the order of 15ns, because there's lots of capacity checks around vectors and the type checks are slightly less optimized than before. Overall though this is still significantly better than today because allocations and the rwlock to acquire the type information are both avoided. I personally feel that this change is the best to do because it has less of an API impact than #3298. * Rebase issues List of files: /wasmtime-44.0.1/tests/all/funcref.rs

7a1b7cdf - Implement RFC 11: Redesigning Wasmtime's APIs (#2897)

Thu, 03 Jun 2021 14:10:53 +0000

Implement RFC 11: Redesigning Wasmtime's APIs (#2897)Implement Wasmtime's new API as designed by RFC 11. This is quite a large commit which has had lots of discussion externally, so for more information it's best to read the RFC thread and the PR thread. List of files: /wasmtime-44.0.1/tests/all/funcref.rs

ffca0fc9 - Fix assertion with cross-store values in `Func::new`

Mon, 16 Nov 2020 19:54:57 +0000

Fix assertion with cross-store values in `Func::new`If a host-defined `Func::new` closure returns values from the wrongstore, this currently trips a debug assertion and causes other issueselsewhere in release mode. This commit adds the same dynamic checksfound in `Func::wrap` in the `Func::new` case today. List of files: /wasmtime-44.0.1/tests/all/funcref.rs

8675fa5a - Fix a memory leak on returning incompatible values (#2424)

Mon, 16 Nov 2020 20:26:48 +0000

Fix a memory leak on returning incompatible values (#2424)This fixes an issue where if a store-incompatible value is returned from a host-defined function then that value is leaked. Practically this means that it's possible to accidentally leak `Func` values, but a simple insertion of a `drop` does the trick! List of files: /wasmtime-44.0.1/tests/all/funcref.rs

58bb5dd9 - wasmtime: Add support for `func.ref` and `table.grow` with `funcref`s

Thu, 18 Jun 2020 18:04:40 +0000

wasmtime: Add support for `func.ref` and `table.grow` with `funcref`s`funcref`s are implemented as `NonNull`.This should be more efficient than using a `VMExternRef` that points at a`VMCallerCheckedAnyfunc` because it gets rid of an indirection, dynamicallocation, and some reference counting.Note that the null function reference is *NOT* a null pointer; it is a`VMCallerCheckedAnyfunc` that has a null `func_ptr` member.Part of #929 List of files: /wasmtime-44.0.1/tests/all/funcref.rs