Changes in lib.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/lib.rs

cde2e04f - Fill out more of the C++ API for components (#11889)

Tue, 21 Oct 2025 19:27:10 +0000

Fill out more of the C++ API for components (#11889)* capi: Add a C++ API for `component::Linker`Just a bare-bones API for now with functionality that's possible to fillout. Notably instantiation and defining functions is not yet possible inC++. Some more feature-parity is also added with the core linkers aswell.* capi: Add bindings for component instances* capi: Delete wasip2.h header fileUpon reflection I realize that this is not actually necessary and isotherwise a duplicate of the functionality in `wasi.h`. All of thefunctionality in `wasi.h` is already supported to power WASIp2-definedAPIs in a linker, which is enabled by the `WasiView` trait redirectingto the `WasiView for WasiP1Ctx` implementation. This is similar to howthe `wasmtime` CLI works where a P1 context is always created and thenit's conditionally used for either core wasm or components.Effectively this is a deletion of duplicate functionality in the C APIbut no underlying functionality is lost. Translating information topreexisting WASI calls will work the same as using the wasip2 APIs before.* capi: Start bindings for component functions* capi: Bind component values in the C++ API* capi: Finish bindings for component functions/linkersAll the pieces are now in place to use the C++ API in testing.* Fix compilation of CLI* Fix compile on MSVC* Try again to fix msvc compat* Fix `get_f32` and `get_f64` return values* Fix signed return values* Remove no-longer-needed `capi_transfer` function* Try to fix msvc again* Remove std::optional constructor of `Val`* Fix another namespace clash on msvc* One day I surely may understand a fraction of either C++ or MSVC, buttoday is not that day.* Document internal macro* Add other internal docs List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

69c01c5d - c-api: component-model: Resource table, WASI (#11055)

Wed, 18 Jun 2025 15:05:39 +0000

c-api: component-model: Resource table, WASI (#11055)* c-api: component-model: Resource table, WASI* WASIP2 context builder* Add include* Rename function* Add a simple test* Add comments prtest:full List of files: /wasmtime-44.0.1/crates/c-api/src/lib.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/lib.rs

6ba6e13b - c-api: Compile a component (#10566)

Mon, 14 Apr 2025 16:21:41 +0000

c-api: Compile a component (#10566)* c-api: Compile a componentCo-authored-by: Tyler Rockwood Co-authored-by: Jean-Jacques Lafay * Add documentation to config---------Co-authored-by: Tyler Rockwood Co-authored-by: Jean-Jacques Lafay List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

073aedab - Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

Wed, 09 Apr 2025 21:06:59 +0000

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They're toobig at this time to do through this PR. My hope is that one day in thefuture they'll be migrated, but more realistically that probably won'thappen so these crates just won't benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/c-api/src/lib.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/crates/c-api/src/lib.rs

55bd797a - Extend C API with interfaces needed to use threads (#7940)

Fri, 08 Mar 2024 01:55:34 +0000

Extend C API with interfaces needed to use threads (#7940) List of files: /wasmtime-44.0.1/crates/c-api/src/lib.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/lib.rs

825494fe - Add wasmtime-c-api-impl to the list of crates to publish (#7837)

Mon, 05 Feb 2024 18:05:27 +0000

Add wasmtime-c-api-impl to the list of crates to publish (#7837)* Add wasmtime-c-api-impl to the list of crates to publish* Enable rustdoc and publishing for c-api crate* Provide paths to c-api headers as cargo links metadata* Add a README section about using wasm-c-api in a rust crate* In C API doc comment, mention use case for crates w/ C bindings* Enable publishing for wasmtime-c-api-macros (prtest:full)* Move c-api crates later in the publishing sequence (prtest:full) List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

d4eaacd6 - Add C API for GuestProfiler (#7854)

Mon, 05 Feb 2024 17:34:19 +0000

Add C API for GuestProfiler (#7854)* Add C API for GuestProfiler* GuestProfiler C API: remove unsafe and add docs* Fix clang-format complaints* rename to wasmtime_guestprofiler_t for consistency, change to passing tuples by struct type, clarify docs* rustfmt* out is marked "own" too* gate on profiling feature List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

f7004c19 - c-api: Update reexport of wasmtime crate crate (#7112)

Wed, 18 Oct 2023 20:57:24 +0000

c-api: Update reexport of wasmtime crate crate (#7112)* c-api: Remove reexport of wasmtime crateThis is a follow-up to #6765 to remove this reexport since it wasoriginally added to use both the C API and the `wasmtime` crate in thesame downstream crate, but this should be possible through Cargo with: [dependencies] wasmtime = "13" wasmtime-c-api = { version = "13", package = "wasmtime-c-api" }and that way `wasmtime::*` is available as well as `wasmtime_c_api::*`* Add `pub use wasmtime;` List of files: /wasmtime-44.0.1/crates/c-api/src/lib.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/lib.rs

90e4daff - Make C API usable from Rust (#6765)

Fri, 29 Sep 2023 14:08:05 +0000

Make C API usable from Rust (#6765) List of files: /wasmtime-44.0.1/crates/c-api/src/lib.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/crates/c-api/src/lib.rs

41e13002 - Allow `improper_ctypes_definitions` in C API

Thu, 16 Jul 2020 14:28:59 +0000

Allow `improper_ctypes_definitions` in C APIThis was enabled in rust-lang/rust#72700 but it looks like it's stilltoo noisy for it to be useful to us. List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

d07fdca7 - wasmtime-c-api: Use a safe helper for initializing `MaybeUninit` out pointers

Fri, 10 Jul 2020 18:33:26 +0000

wasmtime-c-api: Use a safe helper for initializing `MaybeUninit` out pointers List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

377b213f - wasmtime-c-api: Remove unused `HostInfoState` struct

Fri, 10 Jul 2020 18:23:30 +0000

wasmtime-c-api: Remove unused `HostInfoState` struct List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs

cca558cd - Remove `HostRef` from the C API (#1926)

Fri, 26 Jun 2020 19:34:34 +0000

Remove `HostRef` from the C API (#1926)This commit removes `HostRef` from the C API which only served the purpose now of converting each type to a `wasm_ref_t*`. Our implementation, however, does not guarantee that you'll get the same `wasm_ref_t*` for each actual underlying item (e.g. if you put a func in a table and then get the func as an export and from the table then `same` will report `false`). Additionally the fate of `wasm_ref_t*` seems somewhat unclear at this point. The change here is to make the `same` and cast functions all abort saying they're unimplemented. (similar to the host info functions). If and when we get around to reimplementing these functions we can ensure they're implemented uniformly and work well for all intended use cases. List of files: /wasmtime-44.0.1/crates/c-api/src/lib.rs