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 c

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 accordingly

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>

* doc-wasm.h: add wasm_tagtype_t documentation and fix wasm_name typo

Add Doxygen documentation for the `wasm_tagtype_t` type and its
associated 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 <[email protected]>

---------

Co-authored-by: Claude Sonnet 4.6 <[email protected]>

show more ...

chore: remove redundant words in comment (#10354)

Signed-off-by: NinaLua <[email protected]>

add clang format (#7601)

* add clang-format

We chose WebKit style because out of all the builtin styles it seems the
closest to what already exists in wasmtime.

Signed-off-by: Tyler Rockwood <rock

add clang format (#7601)

* add clang-format

We chose WebKit style because out of all the builtin styles it seems the
closest to what already exists in wasmtime.

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: don't reorder headers

The order here matters

Signed-off-by: Tyler Rockwood <[email protected]>

* c-api: apply clang-format

Signed-off-by: Tyler Rockwood <[email protected]>

* fiber: apply clang-format

Signed-off-by: Tyler Rockwood <[email protected]>

* runtime: apply clang-format

Signed-off-by: Tyler Rockwood <[email protected]>

* examples: apply clang format

Signed-off-by: Tyler Rockwood <[email protected]>

* tests: apply clang-format

Signed-off-by: Tyler Rockwood <[email protected]>

* ci: add clang-format checks

Signed-off-by: Tyler Rockwood <[email protected]>

* clang-format: keep braces on the same line

This is more the existing style

Signed-off-by: Tyler Rockwood <[email protected]>

* remove clang-format

Just use the tool defaults (LLVM)

Signed-off-by: Tyler Rockwood <[email protected]>

* Fix ci name

Signed-off-by: Tyler Rockwood <[email protected]>

* manually reformat a couple of comments

prtest:full

Signed-off-by: Tyler Rockwood <[email protected]>

* disable formatting for doc-wasm.h

Signed-off-by: Tyler Rockwood <[email protected]>

* manually reformat wasmtime.h

Signed-off-by: Tyler Rockwood <[email protected]>

* disable formatting

To prevent a link from being broken

Signed-off-by: Tyler Rockwood <[email protected]>

* examples: fixing build commands

Signed-off-by: Tyler Rockwood <[email protected]>

* fix parameter comment

Signed-off-by: Tyler Rockwood <[email protected]>

---------

Signed-off-by: Tyler Rockwood <[email protected]>

show more ...

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

Signed-off-by: spacewander <[email protected]>

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 Cranel

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

show more ...

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 inform

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.

show more ...

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
late

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.

show more ...

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

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

show more ...

Propagate optional import names to the wasmtime/C API

With the module linking proposal the field name on imports is now
optional, and only the module is required to be specified. This commit
propaga

Propagate optional import names to the wasmtime/C API

With the module linking proposal the field name on imports is now
optional, and only the module is required to be specified. This commit
propagates this API change to the boundary of wasmtime's API, ensuring
consumers are aware of what's optional with module linking and what
isn't. Note that it's expected that all existing users will either
update accordingly or unwrap the result since module linking is
presumably disabled.

show more ...

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

Same for `wasm_table_grow` and `wasm_table_new` and their `init` values.

wasmtime-c-api: Document new reference types support

Link to C API docs and make a landing page

Spice up the landing page a bit for the C API documentation and then
link to it from a few places to ensure it's discoverable.

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 warnin

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.

show more ...

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 up

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.

show more ...