Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

* Handle OOM in more places in the public API

A bunch of random places:

* Add: `Trap::try_new` to handle OOM

Handle OOM in the rest of Wasmtime's non-component, -async, -compilation APIs (#12858)

* Handle OOM in more places in the public API

A bunch of random places:

* Add: `Trap::try_new` to handle OOM while creating traps
* Use: `TryVec` inside `Func::call_impl_do_call` and `wasm_val_raw_storage` to
hold the args and rets
* Add: `Instance::try_exports` for iterating over an instance's exports while
handling OOM
* `Linker:try_get`, like `Linker::get` but handling OOM
* `Linker:try_get_by_import`, like `Linker::get_by_import` but handling OOM
* Use `try_new` to box things in `SharedMemory::new`
* Use `TryVec` instead of `Vec` in our dynamic tables

* Add OOM tests for most of Wasmtime's public API

Excludes component-, async-, and compilation-related APIs.

* address review feedback

* fix test compilation

* fix c-api

show more ...

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 fill
out. Notably instantiatio

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 fill
out. Notably instantiation and defining functions is not yet possible in
C++. Some more feature-parity is also added with the core linkers as
well.

* capi: Add bindings for component instances

* capi: Delete wasip2.h header file

Upon reflection I realize that this is not actually necessary and is
otherwise a duplicate of the functionality in `wasi.h`. All of the
functionality in `wasi.h` is already supported to power WASIp2-defined
APIs in a linker, which is enabled by the `WasiView` trait redirecting
to the `WasiView for WasiP1Ctx` implementation. This is similar to how
the `wasmtime` CLI works where a P1 context is always created and then
it's conditionally used for either core wasm or components.

Effectively this is a deletion of duplicate functionality in the C API
but no underlying functionality is lost. Translating information to
preexisting 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/linkers

All 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, but
today is not that day.

* Document internal macro

* Add other internal docs

show more ...

Update nightly Rust used in CI (#11755)

* Update nightly Rust used in CI

Keeping it up-to-date

prtest:full

* Fix unused warnings on nightly

* Rename rustdoc feature

* Adjust some removals

Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)

* Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}"

This commit renames the `preview1` module and features to `p1` and does
the same

Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}" (#11380)

* Rename "preview{0,1}" in `wasmtime-wasi` to "p{0,1}"

This commit renames the `preview1` module and features to `p1` and does
the same for `preview0`. This additionally cleans up the test suite a
bit to share more code amongst all the implementaitons and to also move
the p1 tests out of the p2 folder.

This additionally adds a `p2` feature to the `wasmtime-wasi` crate but
it does not currently gate the `p2` module because that'll require some
more refactoring an annotations to get that working.

* Fix build of the CLI

* Fix build of the C API

* Fix bench-api build

* Fix build of examples

* More renamings

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

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

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in tran

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

* Enable `unsafe-attr-outside-unsafe` 2024 edition lint

This commit enables the `unsafe-attr-outside-unsafe` lint in rustc used
in 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 here
are a simple search/replace.

* Another attribute update

* Fix command adapter build

show more ...

wasmtime-c-api: switch from wasi-common to wasmtime-wasi (#8066)

* wasmtime-c-api: switch from using wasi-common to wasmtime-wasi

* Fix WasiP1Ctx references, and stop eagerly opening dirs for preop

wasmtime-c-api: switch from wasi-common to wasmtime-wasi (#8066)

* wasmtime-c-api: switch from using wasi-common to wasmtime-wasi

* Fix WasiP1Ctx references, and stop eagerly opening dirs for preopens

* Add OutputFile to skip async writes in stdout/stderr

---------

Co-authored-by: Trevor Elliott <[email protected]>

show more ...

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 distinguish
between `wasm.h` APIs and `wasmtime.h` API

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 distinguish
between `wasm.h` APIs and `wasmtime.h` APIs, primarily for `Store`-related
types. In general, `WasmFoo` is related to `wasm.h` and `WasmtimeFoo` is related
to `wasmtime.h`.

* `StoreRef` -> `WasmStoreRef`
* Introduce the `WasmStore[Data]` and `WasmStoreContext[Mut]` aliases
* `StoreData` -> `WasmtimeStoreData`
* `CStoreContext[Mut]` -> `WasmtimeStoreContext[Mut]`
* Introduce the `Wasmtime{Store,Caller}` aliases

show more ...

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

Promote wasmtime-wasi::preview2 to root of crate (#7933)

* better top matter

* eliminate wasi-common deprecations from wasmtime-wasi

* wasmtime-wasi: preview2 feature always enabled, so just elimi

Promote wasmtime-wasi::preview2 to root of crate (#7933)

* better top matter

* eliminate wasi-common deprecations from wasmtime-wasi

* wasmtime-wasi: preview2 feature always enabled, so just eliminate it

* rename preview1-on-preview2 feature to just preview1

* wasi-http fix

* dep fixes. change some log::debug! to tracing::debug!

* mv preview2 up to root

and `sed -i 's/crate::preview2/crate/g' **/*.rs`

* fix tests too

* fixes throughout wasmtime-wasi-http

* cli: s/wasmtime_wasi::preview2/wasmtime_wasi

* rustfmt

* fix wasi-async example

* fix docs build (needs wasi-common built to compile examples)

* c-api: use wasi-common directly

i guess we didnt build the c-api in CI with deprecation warnings denied

prtest:full

* fix example required-features

* fix examples CMakeLists build

show more ...

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

* Refactor `wasmtime::FuncType` to hold a handle to its registered type

Rather than holding a copy of the type directly

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

* Refactor `wasmtime::FuncType` to hold a handle to its registered type

Rather 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`'s
parameters and results fast, avoiding any new locking on call hot paths.

This is helping set the stage for further types and `TypeRegistry` refactors
needed for Wasm GC.

* Update the C API for the function types refactor

prtest:full

* rustfmt

* Fix benches build

show more ...

c-api: Support InstancePre (#7140)

* c-api: Support InstancePre

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

* c-api: Consolidate all the instance_pre functionality

Signed-off-by: Tyler

c-api: Support InstancePre (#7140)

* c-api: Support InstancePre

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

* c-api: Consolidate all the instance_pre functionality

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

* c-api: Add async instantiate support to pre instances

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

* c-api: Add star to comment for doxygen

prtest:full

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

---------

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

show more ...

Async support in the C API (#7106)

* c-api: Add a feature for async

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

* c-api: Add support for async config

Signed-off-by: Tyler Rockwood <rock

Async support in the C API (#7106)

* c-api: Add a feature for async

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

* c-api: Add support for async config

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

* c-api: Add support for calling async functions

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

* c-api: Add ability to yield execution of Wasm in a store

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

* c-api: Introduce wasmtime_linker_instantiate_async

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

* c-api: Support defining async host functions

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

* gitignore: ignore cmake cache for examples

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

* examples: Add example of async API in C

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

* c-api: Consolidate async functionality into a single place

Put all the async stuff in it's own header and own rust source file

Also remove the wasmtime_async_continuation_new function, users can just
allocate it directly.

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

* c-api: Make async function safe

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

* c-api: Remove wasmtime_call_future_get_results

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

* c-api: Simplify CHostCallFuture

Move the result translation and hostcall_val_storage usage into an async
function

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

* c-api: Simplify C continuation implementation

Remove the caller, which means that we don't need another struct for the
future implementation.

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

* c-api: Improve async.h documentation

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

* c-api: Cleanup from previous changes

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

* examples: Fix example

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

* c-api: Simplify continuation callback

This gives more duality with calling an async function and also means
that the implementation can pretty much mirror the sync version.

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

* c-api: Fix async.h documentation

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

* c-api: Fix documentation for async.h

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

* c-api: Review feedback

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

* examples: Downgrade async.cpp example to C++11

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

* c-api: initialize continuation with a panic callback

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

* prtest:full

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

---------

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

show more ...

Change the call to unwrap to except with an error message (#6745)

* Change the call to unwrap to except with an error message

* Update crates/c-api/src/linker.rs

* Run rustfmt.

---------

Co-auth

Change the call to unwrap to except with an error message (#6745)

* Change the call to unwrap to except with an error message

* Update crates/c-api/src/linker.rs

* Run rustfmt.

---------

Co-authored-by: Peter Huene <[email protected]>

show more ...

Remove the need to have a `Store` for an `InstancePre` (#5683)

* Remove the need to have a `Store` for an `InstancePre`

This commit relaxes a requirement of the `InstancePre` API, notably its
co

Remove the need to have a `Store` for an `InstancePre` (#5683)

* Remove the need to have a `Store` for an `InstancePre`

This commit relaxes a requirement of the `InstancePre` API, notably its
construction via `Linker::instantiate_pre`. Previously this function
required a `Store<T>` to be present to be able to perform type-checking
on the contents of the linker, and now this requirement has been
removed.

Items stored within a linker are either a `HostFunc`, which has type
information inside of it, or an `Extern`, which doesn't have type
information inside of it. Due to the usage of `Extern` this is why a
`Store` was required during the `InstancePre` construction process, it's
used to extract the type of an `Extern`. This commit implements a
solution where the type information of an `Extern` is stored alongside
the `Extern` itself, meaning that the `InstancePre` construction process
no longer requires a `Store<T>`.

One caveat of this implementation is that some items, such as tables and
memories, technically have a "dynamic type" where during type checking
their current size is consulted to match against the minimum size
required of an import. This no longer works when using
`Linker::instantiate_pre` as the current size used is the one when it
was inserted into the linker rather than the one available at
instantiation time. It's hoped, however, that this is a relatively
esoteric use case that doesn't impact many real-world users.

Additionally note that this is an API-breaking change. Not only is the
`Store` argument removed from `Linker::instantiate_pre`, but some other
methods such as `Linker::define` grew a `Store` argument as the type
needs to be extracted when an item is inserted into a linker.

Closes #5675

* Fix the C API

* Fix benchmark compilation

* Add C API docs

* Update crates/wasmtime/src/linker.rs

Co-authored-by: Andrew Brown <[email protected]>

---------

Co-authored-by: Andrew Brown <[email protected]>

show more ...

c-api: refactor definitions with macroes (#4416)

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

Remove the module linking implementation in Wasmtime (#3958)

* Remove the module linking implementation in Wasmtime

This commit removes the experimental implementation of the module
linking WebA

Remove the module linking implementation in Wasmtime (#3958)

* Remove the module linking implementation in Wasmtime

This commit removes the experimental implementation of the module
linking WebAssembly proposal from Wasmtime. The module linking is no
longer intended for core WebAssembly but is instead incorporated into
the component model now at this point. This means that very large parts
of Wasmtime's implementation of module linking are no longer applicable
and would change greatly with an implementation of the component model.

The main purpose of this is to remove Wasmtime's reliance on the support
for module-linking in `wasmparser` and tooling crates. With this
reliance removed we can move over to the `component-model` branch of
`wasmparser` and use the updated support for the component model.
Additionally given the trajectory of the component model proposal the
embedding API of Wasmtime will not look like what it looks like today
for WebAssembly. For example the core wasm `Instance` will not change
and instead a `Component` is likely to be added instead.

Some more rationale for this is in #3941, but the basic idea is that I
feel that it's not going to be viable to develop support for the
component model on a non-`main` branch of Wasmtime. Additionaly I don't
think it's viable, for the same reasons as `wasm-tools`, to support the
old module linking proposal and the new component model at the same
time.

This commit takes a moment to not only delete the existing module
linking implementation but some abstractions are also simplified. For
example module serialization is a bit simpler that there's only one
module. Additionally instantiation is much simpler since the only
initializer we have to deal with are imports and nothing else.

Closes #3941

* Fix doc link

* Update comments

show more ...

Add `*_unchecked` variants of `Func` APIs for the C API (#3350)

* Add `*_unchecked` variants of `Func` APIs for the C API

This commit is what is hopefully going to be my last installment within

Add `*_unchecked` variants of `Func` APIs for the C API (#3350)

* Add `*_unchecked` variants of `Func` APIs for the C API

This commit is what is hopefully going to be my last installment within
the saga of optimizing function calls in/out of WebAssembly modules in
the C API. This is yet another alternative approach to #3345 (sorry) but
also contains everything necessary to make the C API fast. As in #3345
the general idea is just moving checks out of the call path in the same
style of `TypedFunc`.

This new strategy takes inspiration from previously learned attempts
effectively "just" exposes how we previously passed `*mut u128` through
trampolines for arguments/results. This storage format is formalized
through a new `ValRaw` union that is exposed from the `wasmtime` crate.
By doing this it made it relatively easy to expose two new APIs:

* `Func::new_unchecked`
* `Func::call_unchecked`

These are the same as their checked equivalents except that they're
`unsafe` and they work with `*mut ValRaw` rather than safe slices of
`Val`. Working with these eschews type checks and such and requires
callers/embedders to do the right thing.

These two new functions are then exposed via the C API with new
functions, enabling C to have a fast-path of calling/defining functions.
This fast path is akin to `Func::wrap` in Rust, although that API can't
be built in C due to C not having generics in the same way that Rust
has.

For some benchmarks, the benchmarks here are:

* `nop` - Call a wasm function from the host that does nothing and
returns nothing.
* `i64` - Call a wasm function from the host, the wasm function calls a
host function, and the host function returns an `i64` all the way out to
the original caller.
* `many` - Call a wasm function from the host, the wasm calls
host function with 5 `i32` parameters, and then an `i64` result is
returned back to the original host
* `i64` host - just the overhead of the wasm calling the host, so the
wasm calls the host function in a loop.
* `many` host - same as `i64` host, but calling the `many` host function.

All numbers in this table are in nanoseconds, and this is just one
measurement as well so there's bound to be some variation in the precise
numbers here.

| Name | Rust | C (before) | C (after) |
|-----------|------|------------|-----------|
| nop | 19 | 112 | 25 |
| i64 | 22 | 207 | 32 |
| many | 27 | 189 | 34 |
| i64 host | 2 | 38 | 5 |
| many host | 7 | 75 | 8 |

The main conclusion here is that the C API is significantly faster than
before when using the `*_unchecked` variants of APIs. The Rust
implementation is still the ceiling (or floor I guess?) for performance
The main reason that C is slower than Rust is that a little bit more has
to travel through memory where on the Rust side of things we can
monomorphize and inline a bit more to get rid of that. Overall though
the costs are way way down from where they were originally and I don't
plan on doing a whole lot more myself at this time. There's various
things we theoretically could do I've considered but implementation-wise
I think they'll be much more weighty.

* Tweak `wasmtime_externref_t` API comments

show more ...

Add a `wasmtime_linker_define_func` C API function (#3122)

This exposes the functionality of the `Linker` type where a
store-independent function can be created and inserted, allowing a
linker's f

Add a `wasmtime_linker_define_func` C API function (#3122)

This exposes the functionality of the `Linker` type where a
store-independent function can be created and inserted, allowing a
linker's functions to be used across many stores (instead of requiring
one linker-per-store).

Closes #3110

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 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 ...

Remove `HostRef<T>` from the C API (#1926)

This commit removes `HostRef<T>` from the C API which only served the
purpose now of converting each type to a `wasm_ref_t*`. Our
implementation, however

Remove `HostRef<T>` from the C API (#1926)

This commit removes `HostRef<T>` 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.

show more ...

wasmtime: Rip out incomplete/incorrect externref "host info" support

Better to be loud that we don't support attaching arbitrary host info to
`externref`s than to limp along and pretend we do suppor

wasmtime: Rip out incomplete/incorrect externref "host info" support

Better to be loud that we don't support attaching arbitrary host info to
`externref`s than to limp along and pretend we do support it. Supporting it
properly won't reuse any of this code anyways.

show more ...

C API: expose wasmtime_linker_get_one_by_name() (#1897)

* C API: expose wasmtime_linker_get_one_by_name()

* C API: remove unnecessary 'unsafe' qualifiers

* C API: avoid unnecessary mutable bor

C API: expose wasmtime_linker_get_one_by_name() (#1897)

* C API: expose wasmtime_linker_get_one_by_name()

* C API: remove unnecessary 'unsafe' qualifiers

* C API: avoid unnecessary mutable borrows of the Linker

show more ...