Changes in func.rs

0dbb6f3d - Exceptions: implement C API. (#12861)

Tue, 31 Mar 2026 22:56:28 +0000

Exceptions: implement C API. (#12861)* Exceptions: implement C API.This PR implements C (and C++) API support for Wasm exceptions, onefinal remaining hurdle (aside from fuzz-testing) for making exceptionstier-1 and on-by-default.* Review feedback, and add exnref case to `wasmtime_val_t`.* Review feedback: GC feature guard.* clang-format* add docs to exn.hh.* Remove tag size asserts: broken on 32-bit platforms, but not needed for correctness wrt C struct. List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

8c349a3d - Refactor core wasm host entrypoints (#12366)

Tue, 20 Jan 2026 20:40:02 +0000

Refactor core wasm host entrypoints (#12366)* Refactor core wasm host entrypointsThis commit refactors the internals of how guest functions call out tothe host. Previously Wasmtime had a split where `Func::new`-styleconstructors used one entrypoint and `Func::wrap`-style entrypoints useda different entrypoint. This was required long ago when we had an arrayand native ABI calling convention, but nowadays this is no longerrequired. This refactors things to have a single base-level signaturewhich is the narrow waist through which all other function entrypointsgo through. This enables having a single function handle all the thingslike panicking, call hooks, etc, and everything further builds on top ofit.This commit additionally pushes the async-ness of a function down evenfurther. Previously many `*_async` constructors would quickly delegateto their non-async counterpart, but this is expected to more-or-lessbecome not the right way to do things as wasmtime moves into thefuture. Historical refactorings related to GC, for example, have pushed`async` further down within Wasmtime and this continues that trend.There's no immediate benefit just yet, but this is hoped to make futurerefactorings easier.Along the way some minor API changes happened too:* `*_unchecked` constructors now work with `MaybeUninit` to correctly model how some values may not be initialized.* Some `*_async` functions picked up `T: Send` which should have in theory been required before and are now compiler-required.* Longstanding/old internal functions have been shuffled around/refactored.Finally, another eventual goal of this work is to share more betweencore wasm and components in terms of implementation. Right now thecomponent host function entrypoints are quite different than the corewasm ones and that ideally wouldn't endure forever.* Fix c-api build* Fix dead code* Fix benchmarks build* Review comments List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

dc029724 - Migrate C API to `wasmtime::error` (#12259)

Wed, 07 Jan 2026 21:26:03 +0000

Migrate C API to `wasmtime::error` (#12259) List of files: /wasmtime-44.0.1/crates/c-api/src/func.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/c-api/src/func.rs

ae84e6ed - Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)

Thu, 09 Jan 2025 21:05:55 +0000

Enable `unsafe-attr-outside-unsafe` 2024 edition lint (#9964)* Enable `unsafe-attr-outside-unsafe` 2024 edition lintThis commit enables the `unsafe-attr-outside-unsafe` lint in rustc usedin transitioning to the 2024 edition. This requires that the`#[no_mangle]` attribute is replaced in favor of `#[unsafe(no_mangle)]`.This mostly affects the C API of wasmtime and most of the changes hereare a simple search/replace.* Another attribute update* Fix command adapter build List of files: /wasmtime-44.0.1/crates/c-api/src/func.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/c-api/src/func.rs

0c0153c1 - Enforce `clippy::clone_on_copy` for the workspace (#9025)

Sat, 27 Jul 2024 01:11:06 +0000

Enforce `clippy::clone_on_copy` for the workspace (#9025)* Derive `Copy` for `Val`* Fix `clippy::clone_on_copy` for the whole repo* Enforce `clippy::clone_on_copy` for the workspace* fix some more clippy::clone_on_copy that got missed List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

9187f2d9 - c-api: Create `RootScope` where necessary (#8374)

Mon, 15 Apr 2024 22:20:32 +0000

c-api: Create `RootScope` where necessary (#8374)* c-api: Create `RootScope` where necessaryThis commit changes the `wasmtime_val_t::{from_val, to_val}` methods totake a `RootScope` instead of any `AsContextMut`. This then required anumber of refactorings in callers to ensure that a `RootScope` wascreated for any function that needed one. This is required to ensurethat GC references in the C API aren't forced to live for the entirelifetime of the store.This additionally added `*_unrooted` variants which do the same thingbut don't require `RootScope`. This was needed for when the C API callsout to the embedder through a function call because a new `RootScope`wouldn't work for return values (they're bound to a scope within theclosure when we want them to outlive the closure). In these situationsthough we know a `RootScope` is already present at the entrypoint.Closes #8367* Review comments List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

420fc3d1 - c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)

Fri, 12 Apr 2024 14:35:48 +0000

c-api: Better differentiate between `wasm.h` and `wasmtime.h` APIs (#8344)This renames some types and adds some type aliases to help us better distinguishbetween `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-relatedtypes. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is relatedto `wasmtime.h`.* `StoreRef` -> `WasmStoreRef`* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases* `StoreData` -> `WasmtimeStoreData`* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`* Introduce the `Wasmtime{Store,Caller}` aliases List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

bd2ea901 - Define garbage collection rooting APIs (#8011)

Wed, 06 Mar 2024 00:40:02 +0000

Define garbage collection rooting APIs (#8011)* Define garbage collection rooting APIsRooting prevents GC objects from being collected while they are actively beingused.We have a few sometimes-conflicting goals with our GC rooting APIs:1. Safety: It should never be possible to get a use-after-free bug because the user misused the rooting APIs, the collector "mistakenly" determined an object was unreachable and collected it, and then the user tried to access the object. This is our highest priority.2. Moving GC: Our rooting APIs should moving collectors (such as generational and compacting collectors) where an object might get relocated after a collection and we need to update the GC root's pointer to the moved object. This means we either need cooperation and internal mutability from individual GC roots as well as the ability to enumerate all GC roots on the native Rust stack, or we need a level of indirection.3. Performance: Our rooting APIs should generally be as low-overhead as possible. They definitely shouldn't require synchronization and locking to create, access, and drop GC roots.4. Ergonomics: Our rooting APIs should be, if not a pleasure, then at least not a burden for users. Additionally, the API's types should be `Sync` and `Send` so that they work well with async Rust.For example, goals (3) and (4) are in conflict when we think about how tosupport (2). Ideally, for ergonomics, a root would automatically unroot itselfwhen dropped. But in the general case that requires holding a reference to thestore's root set, and that root set needs to be held simultaneously by all GCroots, and they each need to mutate the set to unroot themselves. That implies`Rc>` or `Arc>`! The former makes the store and GC roottypes not `Send` and not `Sync`. The latter imposes synchronization and lockingoverhead. So we instead make GC roots indirect and require passing in a storecontext explicitly to unroot in the general case. This trades worse ergonomicsfor better performance and support for moving GC and async Rust.Okay, with that out of the way, this module provides two flavors of rootingAPI. One for the common, scoped lifetime case, and another for the rare casewhere we really need a GC root with an arbitrary, non-LIFO/non-scoped lifetime:1. `RootScope` and `Rooted`: These are used for temporarily rooting GC objects for the duration of a scope. Upon exiting the scope, they are automatically unrooted. The internal implementation takes advantage of the LIFO property inherent in scopes, making creating and dropping `Rooted`s and `RootScope`s super fast and roughly equivalent to bump allocation. This type is vaguely similar to V8's [`HandleScope`]. [`HandleScope`]: https://v8.github.io/api/head/classv8_1_1HandleScope.html Note that `Rooted` can't be statically tied to its context scope via a lifetime parameter, unfortunately, as that would allow the creation and use of only one `Rooted` at a time, since the `Rooted` would take a borrow of the whole context. This supports the common use case for rooting and provides good ergonomics.2. `ManuallyRooted`: This is the fully general rooting API used for holding onto non-LIFO GC roots with arbitrary lifetimes. However, users must manually unroot them. Failure to manually unroot a `ManuallyRooted` before it is dropped will result in the GC object (and everything it transitively references) leaking for the duration of the `Store`'s lifetime. This type is roughly similar to SpiderMonkey's [`PersistentRooted`], although they avoid the manual-unrooting with internal mutation and shared references. (Our constraints mean we can't do those things, as mentioned explained above.) [`PersistentRooted`]: http://devdoc.net/web/developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/JSAPI_reference/JS::PersistentRooted.htmlAt the end of the day, both `Rooted` and `ManuallyRooted` are just taggedindices into the store's `RootSet`. This indirection allows working with Rust'sborrowing discipline (we use `&mut Store` to represent mutable access to the GCheap) while still allowing rooted references to be moved around without tying upthe whole store in borrows. Additionally, and crucially, this indirection allowsus to update the *actual* GC pointers in the `RootSet` and support moving GCs(again, as mentioned above).* Reorganize GC-related submodules in `wasmtime-runtime`* Reorganize GC-related submodules in `wasmtime`* Use `Into` for `Externref::data[_mut]` methods* Run rooting tests under MIRI* Make `into_abi` take an `AutoAssertNoGc`* Don't use atomics to update externref ref counts anymore* Try to make lifetimes/safety more-obviously correctRemove some transmute methods, assert that `VMExternRef`s are the only valid`VMGcRef`, etc.* Update extenref constructor examples* Make `GcRefImpl::transmute_ref` a non-default trait method* Make inline fast paths for GC LIFO scopes* Make `RootSet::unroot_gc_ref` an `unsafe` function* Move Hash and Eq for Rooted, move to impl methods* Remove type parameter from `AutoAssertNoGc`Just wrap a `&mut StoreOpaque` directly.* Make a bunch of internal `ExternRef` methods that deal with raw `VMGcRef`s take `AutoAssertNoGc` instead of `StoreOpaque`* Fix compile after rebase* rustfmt* revert unrelated egraph changes* Fix non-gc build* Mark `AutoAssertNoGc` methods inline* review feedback* Temporarily remove externref support from the C APIUntil we can add proper GC rooting.* Remove doxygen reference to temp deleted function* Remove need to `allow(private_interfaces)`* Fix call benchmark compilation List of files: /wasmtime-44.0.1/crates/c-api/src/func.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/crates/c-api/src/func.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/crates/c-api/src/func.rs

37cf8e1e - Async support in the C API (#7106)

Tue, 03 Oct 2023 13:42:56 +0000

Async support in the C API (#7106)* c-api: Add a feature for asyncSigned-off-by: Tyler Rockwood * c-api: Add support for async configSigned-off-by: Tyler Rockwood * c-api: Add support for calling async functionsSigned-off-by: Tyler Rockwood * c-api: Add ability to yield execution of Wasm in a storeSigned-off-by: Tyler Rockwood * c-api: Introduce wasmtime_linker_instantiate_asyncSigned-off-by: Tyler Rockwood * c-api: Support defining async host functionsSigned-off-by: Tyler Rockwood * gitignore: ignore cmake cache for examplesSigned-off-by: Tyler Rockwood * examples: Add example of async API in CSigned-off-by: Tyler Rockwood * c-api: Consolidate async functionality into a single placePut all the async stuff in it's own header and own rust source fileAlso remove the wasmtime_async_continuation_new function, users can justallocate it directly.Signed-off-by: Tyler Rockwood * c-api: Make async function safeSigned-off-by: Tyler Rockwood * c-api: Remove wasmtime_call_future_get_resultsSigned-off-by: Tyler Rockwood * c-api: Simplify CHostCallFutureMove the result translation and hostcall_val_storage usage into an asyncfunctionSigned-off-by: Tyler Rockwood * c-api: Simplify C continuation implementationRemove the caller, which means that we don't need another struct for thefuture implementation.Signed-off-by: Tyler Rockwood * c-api: Improve async.h documentationSigned-off-by: Tyler Rockwood * c-api: Cleanup from previous changesSigned-off-by: Tyler Rockwood * examples: Fix exampleSigned-off-by: Tyler Rockwood * c-api: Simplify continuation callbackThis gives more duality with calling an async function and also meansthat the implementation can pretty much mirror the sync version.Signed-off-by: Tyler Rockwood * c-api: Fix async.h documentationSigned-off-by: Tyler Rockwood * c-api: Fix documentation for async.hSigned-off-by: Tyler Rockwood * c-api: Review feedbackSigned-off-by: Tyler Rockwood * examples: Downgrade async.cpp example to C++11Signed-off-by: Tyler Rockwood * c-api: initialize continuation with a panic callbackSigned-off-by: Tyler Rockwood * prtest:fullSigned-off-by: Tyler Rockwood ---------Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

8bec98da - Fix some beta warnings in the C API (#6578)

Tue, 13 Jun 2023 21:45:50 +0000

Fix some beta warnings in the C API (#6578)This'll make the future upgrade to Rust 1.71 that much more smoother. List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

ec92f8e4 - Make Wasmtime compatible with Stacked Borrows in MIRI (#6338)

Tue, 09 May 2023 14:15:24 +0000

Make Wasmtime compatible with Stacked Borrows in MIRI (#6338)* Make Wasmtime compatible with Stacked Borrows in MIRIThe fact that Wasmtime executes correctly under Tree Borrows but notStacked Borrows is a bit suspect and given what I've since learned aboutthe aliasing models I wanted to give it a stab to get things workingwith Stacked Borrows. It turns out that this wasn't all that difficult,but required two underlying changes:* First the implementation of `Instance::vmctx` is now specially crafted in an intentional way to preserve the provenance of the returned pointer. This way all `&Instance` pointers will return a `VMContext` pointer with the same provenance and acquiring the pointer won't accidentally invalidate all prior pointers.* Second the conversion from `VMContext` to `Instance` has been updated to work with provenance and such. Previously the conversion looked like `&mut VMContext -> &mut Instance`, but I think this didn't play well with MIRI because `&mut VMContext` has no provenance over any data since it's zero-sized. Instead now the conversion is from `*mut VMContext` to `&mut Instance` where we know that `*mut VMContext` has provenance over the entire instance allocation. This shuffled a fair bit around to handle the new closure-based API to prevent escaping pointers, but otherwise no major change other than the structure and the types in play.This commit additionally picks up a dependency on the `sptr` crate whichis a crate for prototyping strict-provenance APIs in Rust. This is Ibelieve intended to be upstreamed into Rust one day (it's in thestandard library as a Nightly-only API right now) but in the meantimethis is a stable alternative.* Clean up manual `unsafe impl Send` implsThis commit adds a new wrapper type `SendSyncPtr` which automaticallyimpls the `Send` and `Sync` traits based on the `T` type contained.Otherwise it works similarly to `NonNull`. This helps clean up anumber of manual annotations of `unsafe impl {Send,Sync} for ...`throughout the runtime.* Remove pointer-to-integer casts with tablesIn an effort to enable MIRI's "strict provenance" mode this commitremoves the integer-to-pointer casts in the runtime `Table`implementation for Wasmtime. Most of the bits were already there totrack all this, so this commit plumbed around the various pointer typesand with the help of the `sptr` crate preserves the provenance of allrelated pointers.* Remove integer-to-pointer casts in CoW managementThe `MemoryImageSlot` type stored a `base: usize` field mostly because Iwas too lazy to have a `Send`/`Sync` type as a pointer, so this commitupdates it to use `SendSyncPtr` and then plumbs the pointer-nessthroughout the implementation. This removes all integer-to-pointer castsand has pointers stores as actual pointers when they're at rest.* Remove pointer-to-integer casts in "raw" representationsThis commit changes the "raw" representation of `Func` and `ExternRef`to a `*mut c_void` instead of the previous `usize`. This is done tosatisfy MIRI's requirements with strict provenance, properly marking theintermediate value as a pointer rather than round-tripping throughintegers.* Minor remaining cleanups* Switch to Stacked Borrows for MIRI on CIAdditionally enable the strict-provenance features to force warningsemitted today to become errors.* Fix a typo* Replace a negative offset with `sub`* Comment the sentinel value* Use NonNull::dangling List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

913efdf2 - wasmtime: Overhaul trampolines (#6262)

Thu, 27 Apr 2023 18:05:44 +0000

wasmtime: Overhaul trampolines (#6262)This commit splits `VMCallerCheckedFuncRef::func_ptr` into three new functionpointers: `VMCallerCheckedFuncRef::{wasm,array,native}_call`. Each one has adedicated calling convention, so callers just choose the version that works forthem. This is as opposed to the previous behavior where we would chain togethermany trampolines that converted between calling conventions, sometimes up tofour on the way into Wasm and four more on the way back out. See [0] fordetails.[0] https://github.com/bytecodealliance/rfcs/blob/main/accepted/tail-calls.md#a-review-of-our-existing-trampolines-calling-conventions-and-call-pathsThanks to @bjorn3 for the initial idea of having multiple function pointers fordifferent calling conventions.This is generally a nice ~5-10% speed up to our call benchmarks across theboard: both Wasm-to-host and host-to-Wasm. The one exception is typed calls fromWasm to the host, which have a minor regression. We hypothesize that this isbecause the old hand-written assembly trampolines did not maintain a call frameand do a tail call, but the new Cranelift-generated trampolines do maintain acall frame and do a regular call. The regression is only a couple nanoseconds,which seems well-explained by these differences explain, and ultimately is not abig deal.However, this does lead to a ~5% code size regression for compiled modules.Before, we compiled a trampoline per escaping function's signature and wededuplicated these trampolines by signature. Now we compile two trampolines perescaping function: one for if the host calls via the array calling conventionand one for it the host calls via the native calling convention. Additionally,we compile a trampoline for every type in the module, in case there is a nativecalling convention function from the host that we `call_indirect` of thattype. Much of this is in the `.eh_frame` section in the compiled module, becauseeach of our trampolines needs an entry there. Note that the `.eh_frame` sectionis not required for Wasmtime's correctness, and you can disable its generationto shrink compiled module code size; we just emit it to play nice with externalunwinders and profilers. We believe there are code size gains available forfollow up work to offset this code size regression in the future.Backing up a bit: the reason each Wasm module needs to provide theseWasm-to-native trampolines is because `wasmtime::Func::wrap` and friends allowembedders to create functions even when there is no compiler available, so theycannot bring their own trampoline. Instead the Wasm module has to supplyit. This in turn means that we need to look up and patch in these Wasm-to-nativetrampolines during roughly instantiation time. But instantiation is super hot,and we don't want to add more passes over imports or any extra work on thispath. So we integrate with `wasmtime::InstancePre` to patch these trampolines inahead of time.Co-Authored-By: Jamey Sharp Co-Authored-By: Alex Crichton prtest:full List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

9c73a448 - c-api: Fix `wasmtime_func_call_unchecked` to communicate all errors (#5262)

Mon, 14 Nov 2022 18:30:17 +0000

c-api: Fix `wasmtime_func_call_unchecked` to communicate all errors (#5262)Change the return value of this function to a `wasmtime_error_t*` instead of the prior `wasm_trap_t*`. This is a leftover from #5149. Closes #5257 List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

2afaac51 - Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)

Wed, 02 Nov 2022 16:29:31 +0000

Return `anyhow::Error` from host functions instead of `Trap`, redesign `Trap` (#5149)* Return `anyhow::Error` from host functions instead of `Trap` This commit refactors how errors are modeled when returned from host functions and additionally refactors how custom errors work with `Trap`. At a high level functions in Wasmtime that previously worked with `Result` now work with `Result` instead where the error is `anyhow::Error`. This includes functions such as: * Host-defined functions in a `Linker` * `TypedFunc::call` * Host-related callbacks like call hooks Errors are now modeled primarily as `anyhow::Error` throughout Wasmtime. This subsequently removes the need for `Trap` to have the ability to represent all host-defined errors as it previously did. Consequently the `From` implementations for any error into a `Trap` have been removed here and the only embedder-defined way to create a `Trap` is to use `Trap::new` with a custom string. After this commit the distinction between a `Trap` and a host error is the wasm backtrace that it contains. Previously all errors in host functions would flow through a `Trap` and get a wasm backtrace attached to them, but now this only happens if a `Trap` itself is created meaning that arbitrary host-defined errors flowing from a host import to the other side won't get backtraces attached. Some internals of Wasmtime itself were updated or preserved to use `Trap::new` to capture a backtrace where it seemed useful, such as when fuel runs out. The main motivation for this commit is that it now enables hosts to thread a concrete error type from a host function all the way through to where a wasm function was invoked. Previously this could not be done since the host error was wrapped in a `Trap` that didn't provide the ability to get at the internals. A consequence of this commit is that when a host error is returned that isn't a `Trap` we'll capture a backtrace and then won't have a `Trap` to attach it to. To avoid losing the contextual information this commit uses the `Error::context` method to attach the backtrace as contextual information to ensure that the backtrace is itself not lost. This is a breaking change for likely all users of Wasmtime, but it's hoped to be a relatively minor change to workaround. Most use cases can likely change `-> Result` to `-> Result` and otherwise explicit creation of a `Trap` is largely no longer necessary. * Fix some doc links * add some tests and make a backtrace type public (#55) * Trap: avoid a trailing newline in the Display impl which in turn ends up with three newlines between the end of the backtrace and the `Caused by` in the anyhow Debug impl * make BacktraceContext pub, and add tests showing downcasting behavior of anyhow::Error to traps or backtraces * Remove now-unnecesary `Trap` downcasts in `Linker::module` * Fix test output expectations * Remove `Trap::i32_exit` This commit removes special-handling in the `wasmtime::Trap` type for the i32 exit code required by WASI. This is now instead modeled as a specific `I32Exit` error type in the `wasmtime-wasi` crate which is returned by the `proc_exit` hostcall. Embedders which previously tested for i32 exits now downcast to the `I32Exit` value. * Remove the `Trap::new` constructor This commit removes the ability to create a trap with an arbitrary error message. The purpose of this commit is to continue the prior trend of leaning into the `anyhow::Error` type instead of trying to recreate it with `Trap`. A subsequent simplification to `Trap` after this commit is that `Trap` will simply be an `enum` of trap codes with no extra information. This commit is doubly-motivated by the desire to always use the new `BacktraceContext` type instead of sometimes using that and sometimes using `Trap`. Most of the changes here were around updating `Trap::new` calls to `bail!` calls instead. Tests which assert particular error messages additionally often needed to use the `:?` formatter instead of the `{}` formatter because the prior formats the whole `anyhow::Error` and the latter only formats the top-most error, which now contains the backtrace. * Merge `Trap` and `TrapCode` With prior refactorings there's no more need for `Trap` to be opaque or otherwise contain a backtrace. This commit parse down `Trap` to simply an `enum` which was the old `TrapCode`. All various tests and such were updated to handle this. The main consequence of this commit is that all errors have a `BacktraceContext` context attached to them. This unfortunately means that the backtrace is printed first before the error message or trap code, but given all the prior simplifications that seems worth it at this time. * Rename `BacktraceContext` to `WasmBacktrace` This feels like a better name given how this has turned out, and additionally this commit removes having both `WasmBacktrace` and `BacktraceContext`. * Soup up documentation for errors and traps * Fix build of the C API Co-authored-by: Pat Hickey List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

f4b90209 - Change wasm-to-host trampolines to take the values_vec size (#4192)

Wed, 01 Jun 2022 14:05:37 +0000

Change wasm-to-host trampolines to take the values_vec size (#4192)* Change wasm-to-host trampolines to take the values_vec size This commit changes the ABI of wasm-to-host trampolines, which are only used right now for functions created with `Func::new`, to pass along the size of the `values_vec` argument. Previously the trampoline simply received `*mut ValRaw` and assumed that it was the appropriate size. By receiving a size as well we can thread through `&mut [ValRaw]` internally instead of `*mut ValRaw`. The original motivation for this is that I'm planning to leverage these trampolines for the component model for host-defined functions. Out of an abundance of caution of making sure that everything lines up I wanted to be able to write down asserts about the size received at runtime compared to the size expected. This overall led me to the desire to thread this size parameter through on the assumption that it would not impact performance all that much. I ran two benchmarks locally from the `call.rs` benchmark and got: * `sync/no-hook/wasm-to-host - nop - unchecked` - no change * `sync/no-hook/wasm-to-host - nop-params-and-results - unchecked` - 5% slower This is what I roughly expected in that if nothing actually reads the new parameter (e.g. no arguments) then threading through the parameter is effectively otherwise free. Otherwise though accesses to the `ValRaw` storage is now bounds-checked internally in Wasmtime instead of assuming it's valid, leading to the 5% slowdown (~9.6ns to ~10.3ns). If this becomes a peformance bottleneck for a particular use case then we should be fine to remove the bounds checking here or otherwise only bounds check in debug mode, otherwise I plan on leaving this as-is. Of particular note this also changes the C API for `*_unchecked` functions where the C callback now receives the size of the array as well. * Add docs List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs

0a0c232a - Fix CI for Rust 1.61.0 (#4164)

Thu, 19 May 2022 15:44:45 +0000

Fix CI for Rust 1.61.0 (#4164)A new version of rustc was released this morning and we have a few small breakages on our CI which need fixing: * A new warning was coming out of the c-api crate about an unneeded `unsafe` block. * The panic message of a task in `cranelift-object` needed updating since the standard library changed how it formats strings with the nul byte. List of files: /wasmtime-44.0.1/crates/c-api/src/func.rs