Remove need for explicit `Config::async_support` knob (#12371)

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async

Remove need for explicit `Config::async_support` knob (#12371)

* Refactor component model host function definitions

Push the `async`-ness down one layer.

* Remove need for explicit `Config::async_support` knob

This commit is an attempt to step towards reconciling "old async" and
"new async" in Wasmtime. The old async style is the original async
support in Wasmtime with `call_async`, `func_wrap_async`, etc, where the
main property is that the store is "locked" during an async operation.
Put another way, a store can only execute at most one async operation at
a time. This is in contrast to "new async" support in Wasmtime with the
component-model-async (WASIp3) support, where stores can have more than
one async operation in flight at once.

This commit does not fully reconcile these differences, but it does
remove one hurdle along the way: `Config::async_support`. Since the
beginning of Wasmtime this configuration knob has existed to explicitly
demarcate a config/engine/store as "this thing requires `async` stuff
internally." This has started to make less and less sense over time
where the line between sync and async has become more murky with WASIp3
where the two worlds comingle. The goal of this commit is to deprecate
`Config::async_support` and make the function not actually do anything.

In isolation this can't simply be done, however, because there are many
load-bearing aspects of Wasmtime that rely on this `async_support` knob.
For example once epochs + yielding are enabled it's required that all
Wasm is executed on a fiber lest it hit an epoch and not know how to
yield. That means that this commit is not a simple removal of
`async_support` but instead a refactoring/rearchitecting of how async is
used internally within Wasmtime. The high-level ideas within Wasmtime
now are:

* A `Store` has a "requires async" boolean stored within it.
* All configuration options which end up requiring async, such as
yielding with epochs, turn this boolean on.
* Creation of host functions which use async
(e.g. `func_wrap_{async,concurrent}`) will also turn this option on.
* Synchronous API entrypoints into Wasmtime ensure that this boolean is
disabled.
* Asynchronous APIs are usable at any time.

This means that the concept of an async store vs a sync store is now
gone. All stores are equally capable of executing sync/async, and the
change now is that dynamically some stores will require that async is
used with certain configuration. Additionally all panicking conditions
around `async_support` have been converted to errors instead. All
relevant APIs already returned an error and things are murky enough now
that it's not necessarily trivial to get this right at the embedder
level. In the interest of avoiding panics all detected async mismatches
are now first-class `wasmtime::Error` values.

The end result of this commit is that `Config::async_support` is a
deprecated `#[doc(hidden)]` function that does nothing. While many
internal changes happened as well as having new tests for all this sort
of behavior this is not expected to have a great impact on external
consumers. In general a deletion of `async_support(true)` is in theory
all that's required. This is intended to make it easier to think about
async/sync/etc in the future with WASIp3 and eventually reconcile
`func_wrap_async` and `func_wrap_concurrent` for example. That's left
for future refactorings however.

prtest:full

* Review comments

* Fix CI failures

show more ...

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

* Migrate wasmtime-cli to `wasmtime::error`

* migrate benches to `wasmtime::error` as well

* Remove new usage of anyhow that snuck in

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

Run CI tests through AddressSanitizer (#10537)

This is similar to running tests in Valgrind (which we should perhaps
also do...) but can be useful for catching use-after-free style bugs
faster than

Run CI tests through AddressSanitizer (#10537)

This is similar to running tests in Valgrind (which we should perhaps
also do...) but can be useful for catching use-after-free style bugs
faster than when a process crashes. Given the unsafe nature of Wasmtime
this is something we should have probably enabled awhile back but
otherwise so long as it doesn't take too long to run on CI seems like an
easy win of a boost-of-confidence.

prtest:asan

show more ...

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `Pooli

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

* Wasmtime: generalize `async_stack_zeroing` knob to cover initialization

This commit moves the knob from the `PoolingInstanceAllocatorConfig` to the
regular `Config` and now controls both whether stacks are zeroed before reuse
and whether they are zeroed before the initial use. The latter doesn't matter
usually, since anonymous mmaps are already zeroed so we don't have to do
anything there, but for no-std environments it is the difference between
manually zeroing the stack or simply using unininitialized memory.

* Fix CLI and test builds

* fix default config value

* fix some more tests

show more ...

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflo

Print an error on async stack overflow (#9304)

* Print an error on async stack overflow

This commit updates Wasmtime's handling of traps on Unix platforms to
print an error message on stack overflow when the guard page is hit.
This is distinct from stack overflow in WebAssembly which raises a
normal trap and can be caught. This is instead to be used on
misconfigured hosts where the async stack is too small or wasm was
allowed to take up too much of the async stack. Currently no error
message is printed and the program simply aborts with a core dump which
can be difficult to debug.

This instead registers the range of the async guard page with the trap
handling infrastructure to test the faulting address and if it lies
within this range. If so then a small message is printed and then the
program is aborted with `libc::abort()`.

This does not impact the safety of any prior embedding or fix any
issues. It's instead intended purely as a diagnostic tool to help users
more quickly understand that stack size configuration settings are the
likely culprit.

* Fix build of c-api and tests

prtest:full

* Fix build on Windows

* Fix a warning on Windows

* Fix dead code on miri

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

clarify custom memory needs to be zero filled (#7565)

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

Introduce API for custom stack memory (#7209)

* Introduce StackMemory and StackMemoryCreator

This allows custom implementations of stack memory to be plugged into
the async functionality for wasmti

Introduce API for custom stack memory (#7209)

* Introduce StackMemory and StackMemoryCreator

This allows custom implementations of stack memory to be plugged into
the async functionality for wasmtime. Currently, stacks are always
mmapped, and this custom allocator allows embedders to use any memory
they would like.

The new APIs are also exposed in the C api.

This has no effect on windows, as our hands are tied with fibers there.

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

* Add test for custom host memory

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

* fix allocator test

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

* Address review comments

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

* Fix lint warnings

prtest:full

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

* fix windows lint warning

prtest:full

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

---------

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

show more ...