Changes in doc-wasm.h

483eb432 - Merge wasm_tag type into wasm_functype / clean up C API tag headers (#12803)

Sat, 21 Mar 2026 15:31:40 +0000

Merge wasm_tag type into wasm_functype / clean up C API tag headers (#12803)* Merge wasm_tag type into wasm_functype / clean up C API tag headers- Move tag type info into wasm.h alongside other core types instead of a separate wasmtime/tag.h header- Remove wasmtime/tag.h (contents merged into wasm.h / wasm.hh)- Update extern.hh and tag.hh to reflect new layout- Add tag param accessors in func.rs- Refactor tag.rs to match updated C API surface- Update tag_type.cc tests accordinglyCo-Authored-By: Claude Sonnet 4.6 * doc-wasm.h: add wasm_tagtype_t documentation and fix wasm_name typoAdd Doxygen documentation for the `wasm_tagtype_t` type and itsassociated functions (`wasm_tagtype_new`, `wasm_tagtype_functype`,vec helpers, and externtype conversion functions). Also document`WASM_EXTERN_TAG` and the `wasm_tagtype_as_externtype*` /`wasm_externtype_as_tagtype*` conversion functions.Fix pre-existing typo: `wasm_name_new_new_uninitialized` ->`wasm_name_new_uninitialized`.Co-Authored-By: Claude Sonnet 4.6 ---------Co-authored-by: Claude Sonnet 4.6 List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

665c098a - chore: remove redundant words in comment (#10354)

Fri, 07 Mar 2025 12:58:50 +0000

chore: remove redundant words in comment (#10354)Signed-off-by: NinaLua List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

f8fee938 - add clang format (#7601)

Wed, 29 Nov 2023 18:39:04 +0000

add clang format (#7601)* add clang-formatWe chose WebKit style because out of all the builtin styles it seems theclosest to what already exists in wasmtime.Signed-off-by: Tyler Rockwood * c-api: don't reorder headersThe order here mattersSigned-off-by: Tyler Rockwood * c-api: apply clang-formatSigned-off-by: Tyler Rockwood * fiber: apply clang-formatSigned-off-by: Tyler Rockwood * runtime: apply clang-formatSigned-off-by: Tyler Rockwood * examples: apply clang formatSigned-off-by: Tyler Rockwood * tests: apply clang-formatSigned-off-by: Tyler Rockwood * ci: add clang-format checksSigned-off-by: Tyler Rockwood * clang-format: keep braces on the same lineThis is more the existing styleSigned-off-by: Tyler Rockwood * remove clang-formatJust use the tool defaults (LLVM)Signed-off-by: Tyler Rockwood * Fix ci nameSigned-off-by: Tyler Rockwood * manually reformat a couple of commentsprtest:fullSigned-off-by: Tyler Rockwood * disable formatting for doc-wasm.hSigned-off-by: Tyler Rockwood * manually reformat wasmtime.hSigned-off-by: Tyler Rockwood * disable formattingTo prevent a link from being brokenSigned-off-by: Tyler Rockwood * examples: fixing build commandsSigned-off-by: Tyler Rockwood * fix parameter commentSigned-off-by: Tyler Rockwood ---------Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

1ae8ba2d - doc: wasm_functype_new takes ownership of its input (#3957)

Wed, 23 Mar 2022 04:04:57 +0000

doc: wasm_functype_new takes ownership of its input (#3957)Signed-off-by: spacewander List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

e68aa995 - Implement the memory64 proposal in Wasmtime (#3153)

Thu, 12 Aug 2021 14:40:20 +0000

Implement the memory64 proposal in Wasmtime (#3153)* Implement the memory64 proposal in Wasmtime This commit implements the WebAssembly [memory64 proposal][proposal] in both Wasmtime and Cranelift. In terms of work done Cranelift ended up needing very little work here since most of it was already prepared for 64-bit memories at one point or another. Most of the work in Wasmtime is largely refactoring, changing a bunch of `u32` values to something else. A number of internal and public interfaces are changing as a result of this commit, for example: * Acessors on `wasmtime::Memory` that work with pages now all return `u64` unconditionally rather than `u32`. This makes it possible to accommodate 64-bit memories with this API, but we may also want to consider `usize` here at some point since the host can't grow past `usize`-limited pages anyway. * The `wasmtime::Limits` structure is removed in favor of minimum/maximum methods on table/memory types. * Many libcall intrinsics called by jit code now unconditionally take `u64` arguments instead of `u32`. Return values are `usize`, however, since the return value, if successful, is always bounded by host memory while arguments can come from any guest. * The `heap_addr` clif instruction now takes a 64-bit offset argument instead of a 32-bit one. It turns out that the legalization of `heap_addr` already worked with 64-bit offsets, so this change was fairly trivial to make. * The runtime implementation of mmap-based linear memories has changed to largely work in `usize` quantities in its API and in bytes instead of pages. This simplifies various aspects and reflects that mmap-memories are always bound by `usize` since that's what the host is using to address things, and additionally most calculations care about bytes rather than pages except for the very edge where we're going to/from wasm. Overall I've tried to minimize the amount of `as` casts as possible, using checked `try_from` and checked arithemtic with either error handling or explicit `unwrap()` calls to tell us about bugs in the future. Most locations have relatively obvious things to do with various implications on various hosts, and I think they should all be roughly of the right shape but time will tell. I mostly relied on the compiler complaining that various types weren't aligned to figure out type-casting, and I manually audited some of the more obvious locations. I suspect we have a number of hidden locations that will panic on 32-bit hosts if 64-bit modules try to run there, but otherwise I think we should be generally ok (famous last words). In any case I wouldn't want to enable this by default naturally until we've fuzzed it for some time. In terms of the actual underlying implementation, no one should expect memory64 to be all that fast. Right now it's implemented with "dynamic" heaps which have a few consequences: * All memory accesses are bounds-checked. I'm not sure how aggressively Cranelift tries to optimize out bounds checks, but I suspect not a ton since we haven't stressed this much historically. * Heaps are always precisely sized. This means that every call to `memory.grow` will incur a `memcpy` of memory from the old heap to the new. We probably want to at least look into `mremap` on Linux and otherwise try to implement schemes where dynamic heaps have some reserved pages to grow into to help amortize the cost of `memory.grow`. The memory64 spec test suite is scheduled to now run on CI, but as with all the other spec test suites it's really not all that comprehensive. I've tried adding more tests for basic things as I've had to implement guards for them, but I wouldn't really consider the testing adequate from just this PR itself. I did try to take care in one test to actually allocate a 4gb+ heap and then avoid running that in the pooling allocator or in emulation because otherwise that may fail or take excessively long. [proposal]: https://github.com/WebAssembly/memory64/blob/master/proposals/memory64/Overview.md * Fix some tests * More test fixes * Fix wasmtime tests * Fix doctests * Revert to 32-bit immediate offsets in `heap_addr` This commit updates the generation of addresses in wasm code to always use 32-bit offsets for `heap_addr`, and if the calculated offset is bigger than 32-bits we emit a manual add with an overflow check. * Disable memory64 for spectest fuzzing * Fix wrong offset being added to heap addr * More comments! * Clarify bytes/pages List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

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/include/doc-wasm.h

f94db655 - Update WebAssembly C API submodule to latest commit. (#2579)

Thu, 14 Jan 2021 15:36:12 +0000

Update WebAssembly C API submodule to latest commit. (#2579)* Update WebAssembly C API submodule to latest commit. This commit updates the WebAssembly C API submodule (for `wasm.h`) to the latest commit out of master. This fixes the behavior of `wasm_name_new_from_string` such that it no longer copies the null character into the name, which caused unexpected failures when using the Wasmtime linker as imports wouldn't resolve when the null was present. Along with this change were breaking changes to `wasm_func_call`, the host callback signatures, and `wasm_instance_new` to take a vector type instead of a pointer to an unsized array. As a result, Wasmtime language bindings based on the C API will need to be updated once this change is pulled in. Fixes #2211. Fixes #2131. * Update Doxygen comments for wasm.h changes. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

41caf67a - Update the C API with module linking support (#2472)

Thu, 03 Dec 2020 21:51:38 +0000

Update the C API with module linking support (#2472)* Update the C API with module linking support This commit does everything necessary (ideally) to support the module linking proposal in the C API. The changes here are: * New `wasm_{module,instance}type_t` types and accessors * New `wasm_{module,instance}_type` functions * Conversions between `wasm_extern_t` and `wasm_{instance,module}_t`, as well as `wasm_externtype_t` and the new types. * Addition of `WASM_EXTERN_{MODULE,INSTANCE}` constants * New `wasm_config_t` modifier to enable/disable module linking With these functions it should be possible to pass instances/modules to instances and also acquire them from exports. Altogether this should enable everything for module linking. An important point for this is that I've opted to add all these items under the `wasm_*` name prefix instead of `wasmtime_*`. I've done this since they're all following the idioms of existing APIs and while not standard the intention would be to standardize them (unlike many other Wasmtime-specific APIs). cc #2094 * Appease doxygen List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

62be6841 - Propagate optional import names to the wasmtime/C API

Mon, 23 Nov 2020 23:17:34 +0000

Propagate optional import names to the wasmtime/C APIWith the module linking proposal the field name on imports is nowoptional, and only the module is required to be specified. This commitpropagates this API change to the boundary of wasmtime's API, ensuringconsumers are aware of what's optional with module linking and whatisn't. Note that it's expected that all existing users will eitherupdate accordingly or unwrap the result since module linking ispresumably disabled. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

89603bc6 - wasmtime-c-api: Make `wasm_table_set` not take ownership of its reference

Fri, 10 Jul 2020 19:03:03 +0000

wasmtime-c-api: Make `wasm_table_set` *not* take ownership of its referenceSame for `wasm_table_grow` and `wasm_table_new` and their `init` values. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

4c01ffd0 - wasmtime-c-api: Document new reference types support

Wed, 08 Jul 2020 18:36:40 +0000

wasmtime-c-api: Document new reference types support List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

920e0984 - Link to C API docs and make a landing page

Thu, 02 Jul 2020 15:49:27 +0000

Link to C API docs and make a landing pageSpice up the landing page a bit for the C API documentation and thenlink to it from a few places to ensure it's discoverable. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

47a218f9 - Document the rest of the C API (#1959)

Thu, 02 Jul 2020 14:26:10 +0000

Document the rest of the C API (#1959)This commit fills out documentation for all remaining functions in the C API, and additionally enables "warn if undocumented" which will fail CI since warnings are also treated as errors. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h

d72b330d - Add support for documenting the C API (#1928)

Wed, 01 Jul 2020 19:05:18 +0000

Add support for documenting the C API (#1928)This commit adds a bit of a skeleton of what it might look like to document the C API. Today the C API has virtually zero documentation because the upstream documentation does not exist and we haven't put a ton of effort into documenting our own extensions. Given that this is one of the main vectors we expect users to use Wasmtime, we should make sure it's thoroughly documented! I've never really done much documentation generation of C myself before, but I did a bit of searching and Doxygen seems reasonable proficient for doing this. This commit sets up what it might look like for Doxygen to be used for the C API. One nice feature of DOxygen is that we can document the items in `wasm.h` without actually modifying `wasm.h`. For those purposes a `doc-wasm.h` file was added here which is where we can put Wasmtime-specific documentation about `wasm.h`. There's quite a few functions in the C API so I didn't want to get them all done before getting consensus on this. I've started some skeletons of documentation for global types in `wasm.h` and also confirmed that documentation works for our own `wasmtime.h` and such header files. If this looks good to everyone and it runs reasonable well on CI then I can spend more time filling out the rest of the documentation. List of files: /wasmtime-44.0.1/crates/c-api/include/doc-wasm.h