Consume hostcall fuel when buffering stream data in the host (#12767)

For guest-to-guest communication stream reads/writes rendezvousing
together will currently copy data through `Val`. This is expe

Consume hostcall fuel when buffering stream data in the host (#12767)

For guest-to-guest communication stream reads/writes rendezvousing
together will currently copy data through `Val`. This is expected to
become more optimized in the future, but for now this needs to consume
the concept of "hostcall fuel" introduced in #12652 to ensure that the
guest can't exhaust memory in the host. This additionally tweaks some
hostcall fuel calculations to more accurately reflect the size of values
on the host, notably by using `size_of::<Thing>()` on the host rather
than the size in the guest.

Closes #12674

show more ...

Fix two security advisories. (#12652)

* Fix two security advisories.

This commit contains merged fixes for two security advisories in
Wasmtime:

* GHSA-852m-cvvp-9p4w
* GHSA-243v-98vx-264h

This in

Fix two security advisories. (#12652)

* Fix two security advisories.

This commit contains merged fixes for two security advisories in
Wasmtime:

* GHSA-852m-cvvp-9p4w
* GHSA-243v-98vx-264h

This introduces new knobs to Wasmtime to limit the scope of resources
that WASI implementations will allocate on behalf of guests. Unlike
backports to 41.0.x-and-prior these knobs all have default values which
are considered reasonable for hosts if they don't further tune them. The
following CLI knobs have been added:

* `-Smax-resources` - limits the total component-model resources a guest
can allocate in a table
* `-Shostcall-fuel` - a broad limit which enforces that at most this
amount of data will be copied from the guest to the host in any one
API call (e.g. `string` values can't be too big, `list<string>` can't
be quadratic, etc). This fuel is reset on each host function call.
* `-Smax-random-size` - the maximal size of the return value of the
`get-random-bytes` and `get-insecure-random-bytes` WASI functions.
* `-Smax-http-fields-size` - a limit on the size of `wasi:http` `fields`
values to avoid infinitely buffering data within the host.

The `http` crate has additionally been updated to avoid a panic when
adding too many headers to a `fields` object.

Co-authored-by: Mark Bundschuh <[email protected]>
Co-authored-by: Pat Hickey <[email protected]>
Co-authored-by: Joel Dice <[email protected]>

* CI fixes

* Run rustfmt
* Fix wasi-common build

* Fix tests on 32-bit

* Fix nightly test expectations

prtest:full

---------

Co-authored-by: Mark Bundschuh <[email protected]>
Co-authored-by: Pat Hickey <[email protected]>
Co-authored-by: Joel Dice <[email protected]>

show more ...

Refactor borrow state tracking for async tasks (#12550)

* Refactor borrow state tracking for async tasks

This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for b

Refactor borrow state tracking for async tasks (#12550)

* Refactor borrow state tracking for async tasks

This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for both the host and the guest with respect to
async tasks. This additionally refactors how some async task management
is done for host-called functions.

The fundamental problem being tackled here is #12510. In that issue it
was discovered that the way `CallContext`, the borrow tracking mechanism
in Wasmtime, is managed is incompatible with async tasks. Specifically
the previous assumption of the scope being mutated for a borrow is
somewhere on the call stack is no longer true. It's possible for an
async task to be suspended, for example, and then a sibling task drops a
borrow which should update the scope of the suspended task. There were a
number of other small issues I noticed here and there which this PR
additionally has tests for, all of which failed before this change and
pass afterwards.

The manner in which borrow state is manipulated is a pretty old part of
the component model implementation dating back to the original
implementation of resources. I decided to forgo any possible quick fix
and have attempted to more deeply refactor and integrate async tasks
into all of this infrastructure. A list of the changes made here are:

* The `CallContexts` structure, a stack of `CallContext`, was removed.
Tasks now directly store a `CallContext` which is the source of truth
for borrow tracking for that call, and it does not move from this
location. The store `CallContexts` is now deleted in favor of updating
the `Option<ConcurrentState>` in the store to be an `enum` of either
concurrent state or a stack. In this manner the old stack-based
structure is still used sometimes, but it's impossible to reach when
concurrency is enabled.

* Entry to the host from guests now reliably pushes a `HostTask` into
the store. Previously where a frame were always pushed into a
`CallContext` a `HostTask` is pushed into the store. This is still
expected to be a bit too expensive for cheap host calls, but it
doesn't meaningfully change the performance profile of before.

* The `resource_enter_call` and `resource_exit_call` libcalls have been
removed. These are now folded into the `enter_sync_call` and
`exit_sync_call` libcalls. Emission of these hooks has been updated
accordingly. The concept of entering a call more generally has been
removed. This is more formally known in the async world as a task
starting, so the task creation is now responsible for the demarcation
of entering a call. Additionally this means that the concept of
exiting a call has somewhat gone away. Instead this method was renamed
to `validate_scope_exit` which double-checks that a borrow-scope can
be exited but doesn't actually remove the task. Task removal is
deferred to preexisting mechanisms.

* Management of a `GuestTask`'s previous `Option<CallContext>` field,
for example taking/restoring and pushing/popping onto `CallContexts`
is now all gone. All related code is outright deleted as the
`GuestTask`'s now non-optional `CallContext` field is the source of truth.

* The `ConcurrentState` structure now stores a `CurrentThread` enum
instead of `Option<QualifiedThreadId>`. This represents how the
currently executing thread could be a host thread, not just a guest
thread, which is required for borrow-tracking.

* `HostTask` creation in `poll_and_block` and `first_poll`, the two main
entrypoints of async host tasks when called by the guest, is now
externalized from these functions. Instead these functions assume that
the currently running thread is already a `HostTask` of some kind.

* In `poll_and_block` the host's result is no longer stored in the guest
task but in the host task instead.

Overall this enables the `*.wast` test for #12510 to fix the original
issue. This then adds new tests to ensure that cleanup of various
constructs happens appropriately, such as cancelling a host task should
clean up its associated resources. Additionally synchronously calling an
async host task no longer leaks resources in a `Store` and should
properly clean up everything.

There is still more work to do in this area (e.g. #12544) but that's
going to be deferred to a future PR at this point.

Closes #12510

prtest:full

* Review comments/CI fixes

show more ...

Move `ResourceTables` constructors to `StoreOpaque` (#12546)

* Move `ResourceTables` constructors to `StoreOpaque`

This is intended to consolidate where they're constructed, provide
access to the h

Move `ResourceTables` constructors to `StoreOpaque` (#12546)

* Move `ResourceTables` constructors to `StoreOpaque`

This is intended to consolidate where they're constructed, provide
access to the host data at all times, and pave the way for a future
refactoring here to touch fewer lines.

* Fix a cfg

show more ...

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

Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)

* Only create `ConcurrentState` in a `Store` when CM async is enabled

Creating the default `ConcurrentState` will create

Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)

* Only create `ConcurrentState` in a `Store` when CM async is enabled

Creating the default `ConcurrentState` will create a `FuturesUnordered` which
will allocate. By making this state optional, we can keep making progress on
https://github.com/bytecodealliance/wasmtime/issues/12069, and put off dealing
with `FuturesUnordered` until when we are ready to try and make CM async code
handle OOMs.

* Support dynamically disabling component-model-async at runtime

* fix warnings in certain cfg builds

* fix another warning

* Forcibly enable CM async for a couple wast tests

show more ...

refactor recursive reentrance checks (#12349)

* refactor recursive reentrance checks

This commit makes a few changes related to recursive reentrance checks, instance
poisoning, etc.:

- Implements

refactor recursive reentrance checks (#12349)

* refactor recursive reentrance checks

This commit makes a few changes related to recursive reentrance checks, instance
poisoning, etc.:

- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis.
- Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated.
- This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.
- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.
- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.

Note that this does _not_ include code to push and pop `GuestTask` instances for
guest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. the
synchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`
to be present such as `backpressure.inc` will still fail in such cases. I'll
address that in a later PR.

Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`
bound on the `T` type parameter for `store | async` functions. This allowed me
to recursively call `{Typed}Func::call_concurrent` from inside a host function,
and it doesn't have any downsides AFAICT.

Fixes #12128

* bless bindgen expansions

* bless disas tests

* address review feedback

* sync `trap.h` with `trap_encoding.rs`

...and add const assertions to `trap.rs` to help avoid future divergence.

show more ...

allow recursive Wasm invocation from concurrent host functions (#12152)

* allow recursive Wasm invocation from concurrent host functions

The core changes here are:

- remove an unnecessary assertio

allow recursive Wasm invocation from concurrent host functions (#12152)

* allow recursive Wasm invocation from concurrent host functions

The core changes here are:

- remove an unnecessary assertion from `concurrent::prepare_call`
- track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis
- both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally unique

While discussing the above with Alex, we realized the use of a `HashMap` to
track per-instance states was both pessimal and unnecessary. Consequently, I've
folded that state into `ComponentInstance::instance_handle_tables`, renaming it
to `instance_states`. That involved a fair amount of code churn, but doesn't
change behavior except as described in the second bullet point above.

Thanks to Alex for the test case!

Fixes #12098

Co-authored-by: Alex Crichton <[email protected]>
Signed-off-by: Joel Dice <[email protected]>

* use new `RuntimeInstance` type instead of tuples

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...

Enable borrowing components and stores mutable at the same time (#11987)

* Use `OptionsIndex` more internally in components

This updates various runtimes bits for components to use `OptionsIndex`

Enable borrowing components and stores mutable at the same time (#11987)

* Use `OptionsIndex` more internally in components

This updates various runtimes bits for components to use `OptionsIndex`
more aggressively and ultimately deletes the old `Options` type. The
`Options` type is a heavyweight package of all possible options which is
effectively a duplication of what `OptionsIndex` points to, so that's
removed in favor of directly accessing options.

* Enable borrowing components and stores mutable at the same time

This commit adds a new, safe, function to the `Instance` type for
internal use in Wasmtime which enables simultaneously borrowing the
`Component`-within-the-`Instance` as well as the original store at the
same time. This is not possible to do in safe Rust when the store is
mutable and must be implemented with `unsafe` code.

The motivation for this commit is performance. In #11974 it was
discovered that the addition of a single `Arc::clone` was enough to
reduce throughput in the embedding by 20%. While `Arc::clone` is
generally cheap I can see how a "contended" `Arc::clone` could get quite
expensive. This particular benchmark was running multiple instances of
the same component across multiple threads which were all doing many
host calls. Each host call, after the refactoring of #10959, contained
an `Arc::clone` to the component itself. This in turn led to many
threads constantly incrementing/decrementing the `Arc::clone` count of
the same `Arc` instance.

At a high level this clone is not necessary. The component lives within
the store and cannot be mutated/deleted during execution. Safe Rust,
however, forbids access to the component and mutably using the store at
the same time. Thus, this helper function enters the picture. The goal
here is to remove the `Arc::clone` calls without requiring major surgery
or such to refactor the implementations of various functions throughout
Wasmtime. The `unsafe` block used to implement this function documents
more rationale as to why this should be safe.

* Update crates/wasmtime/src/runtime/component/instance.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests pa

Integrate wizer into this repository (#11805)

* Remove misc wizer-related files

* Integrate the Wizer manifest with this repo's workspace

* Enable some more wasmtime features

* Get wizer tests passing in-repo

* Remove duplicate dummy wizer module

* Integer `wasmtime wizer` subcommand into the CLI

* Fully integrate wizer into `wasmtime` CLI

* Split `wasmtime run` into helper functions
* Split `Wizer::run` into helper functions
* Weave the two together in `wasmtime wizer`

The end goal is to have all CLI options in `wasmtime run` applicable for
`wasmtime wizer` as well with some light edits between the two. Overall
though we shouldn't have to proactively support commands in one or the
other and everything ideally should "just work".

* Fix clippy warnings and bench compiles

* Fix benchmarks

* Create a store-per-iteration
* Use the right wasms in the regex benchmark

* Get wizer fuzzer building again

* Get CLI working again

* Run rustfmt

* Remove precompiled wasms from the tree

35M for some wasms is a bit heavy so instead build them from source.

* Update vet configuration for fuzzers/tests

* Update publish script with wasmtime-wizer

* Fix clippy lint

* Some docs and more clippy lints

prtest:full

* Relax version requirement

* Try to fix asan build

* Remove rustflags too

* Un-exclude wizer

* Adjust publish script

* Update lock file after rebase

* Integrate bytecodealliance/wizer#139

Use deterministic results for relaxed simd operations by default.

* Handle preloads in wizer

* Appease clippy

* Use deterministic relaxed simd in wizer tests

show more ...

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

* move `ConcurrentState` from `ComponentInstance` to `Store`

This has a few benefits:

- No need to specify an instance when crea

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

* move `ConcurrentState` from `ComponentInstance` to `Store`

This has a few benefits:

- No need to specify an instance when creating or piping from a stream or future.
- No need to track the instance in an `Accessor`.
- You may now execute tasks for multiple instances in a single event loop.

The main drawback is that, if one of several instances within a single store
traps, it effectively means all instances have trapped, and the store can't be
used to create new instances. The way to avoid that is to use separate stores
for instances which must be isolated from others.

As a result of this change, a lot of code had to move from e.g. `impl Instance`
to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changes
themselves are almost entirely non-functional.

Fixes #11226

Signed-off-by: Joel Dice <[email protected]>

* fix non-component-model-async build

Signed-off-by: Joel Dice <[email protected]>

* fix outdated doc comment

Signed-off-by: Joel Dice <[email protected]>

* address review feedback

- restore `ComponentStoreData` encapsulation
- avoid conditional code duplication in `LiftContext::new`

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

use a single table per instance for resources, waitables, etc. (#11374)

* use a single table per instance for resources, waitables, etc.

Per https://github.com/WebAssembly/component-model/pull/513,

use a single table per instance for resources, waitables, etc. (#11374)

* use a single table per instance for resources, waitables, etc.

Per https://github.com/WebAssembly/component-model/pull/513, the spec now puts
resources, waitables, waitable sets, subtasks, and error contexts in the same
table per instance. This updates the implementation to match.

- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure

- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`

- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above

- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`

While I was doing table-related things, I also updated `concurrent::Table::new`
to reserve the zero handle to mean "invalid". This won't affect what the guest
sees in any way, but it allows us to use `TableId::new(0)` to invalidate
host-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.

Fixes #11189

Signed-off-by: Joel Dice <[email protected]>

Re-internalize `ResourceKind` to `mod handle_table`

Remove `ResourceKind`

Start flattening the representation of `Slot`

Internalize `get_mut_handle_by_index`

Internalize implementation details such as the representation of slots
to and make methods a bit more targeted in their functionality.

Internalize more details of `HandleTable`

Don't expose `HandleKind` and of per-function methods for operating on
the various kinds of handles that reside in the table.

Flatten the representation of `Slot`

There's still some more work to do for host/guest resource handles, but
this helps realize the goal of the previous refactorings in the
meantime.

* stop using `HandleTable::reps_to_indexes` when delivering events

Per review feedback, we'd like to get rid of `HandleTable::reps_to_indexes`
entirely. This commit doesn't go quite that far, but now we only use it for
`error-context` handles. For waitables, which can only be referenced by at most
one guest at a time, we now store the guest handle in `WaitableCommon::handle`
and retrieve it from there when delivering an event for that waitable.

For `error-context` handles, the spec requirement that we always lower the same
handle for the same `error-context`, combined with the fact that an
`error-context` may be referenced by more than one component instance at a time,
means we still need some general way to convert a host rep plus component index
into a handle. Going forward, we could consider either removing that "same
handle" requirement from the spec or consider an alternative implementation
(e.g. storing a `HashMap<RuntimeComponentIndex, usize>` in the `ErrorContext`
host state for keeping track of the handles for each referencing instance.

Signed-off-by: Joel Dice <[email protected]>

* remove `HandleTable::reps_to_indexes`

Turns out the spec no longer requires that guests receive the same handle for a
given `error-context` as the one they already have, so we no longer need this
field -- nor do we need to maintain a per-component-instance reference count.

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

optimize host stream/future writes for flat payloads (#11364)

* optimize host stream/future writes for flat payloads

When we know statically that a payload will not require any guest realloc calls

optimize host stream/future writes for flat payloads (#11364)

* optimize host stream/future writes for flat payloads

When we know statically that a payload will not require any guest realloc calls
to lower, there's no need to defer the lowering to a fiber -- we can just do it
immediately.

Signed-off-by: Joel Dice <[email protected]>

* replace `ComponentType::IS_FLAT_TYPE` with `MAY_REQUIRE_REALLOC`

Per review comments, this more clearly conveys the purpose of the constant.
I've also added a doc comment about what it means and how it is used.

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

ensure component value lowerings are run on a worker fiber (#11353)

* ensure component value lowerings are run on a worker fiber

This is necessary because lowering a component value may require cal

ensure component value lowerings are run on a worker fiber (#11353)

* ensure component value lowerings are run on a worker fiber

This is necessary because lowering a component value may require calling
realloc, which may involve epoch interruption, which may require suspending the
current fiber. Which obviously doesn't work if we're not running in a fiber.
Also, we need to make sure there are no host frames on the stack.

Note the use of `Mutex` for `WorkItem::WorkerFunction` and
`WorkerItem::Function`. We never lock the mutex -- it's only used to plumb
through the inner, non-`Sync` value while satisfying the compiler that `Store`
is `Sync`.

Signed-off-by: Joel Dice <[email protected]>

* add "we're on a fiber" assertion to `LowerContext::new`

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runti

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runtime. Previously options were "exploded"
meaning that options were all passed around as parameters but this was a
bummer for a few reasons:

* This is `unsafe`-prone as options have raw pointers such as memory and
functions. This meant that all functions/operations working with
options were fundamentally `unsafe`.

* This was unwieldy as the set of options continues to grow larger over
time. The `VMLoweringCallee` function previously had 10+ parameters,
most of which were canonical ABI options.

To solve these two problems options are now intern'd at compile time to
an `OptionsIndex`, a 32-bit value. This is stored as a new table in
component metadata and consulted at runtime. This means that
`OptionsIndex` can be passed around with an instance for a much safer
means of threading options around. Additionally there's no need to pass
around all parameters individually and instead just one parameter,
`OptionsIndex`, need be threaded through.

This commit additionally overhauls trampoline generation for the
component compiler to avoid a function-per-intrinsic and instead have a
single function that all intrinsics use. I found this easier to
understand and helps codify that all intrinsics are basically the same
with some minor details differing between them.

The end result of this is (hopefully) a net simplification of the
component compiler in addition to a large amount of removal of `unsafe`
code in the async implementation as only safe types are passed around
now instead of raw pointers.

Closes #10143
Closes #11188

* Fill out some TODO comments

show more ...

Remove `Arc::clone` when creating `LiftContext` (#11253)

A small amount of `unsafe` code is required to enable this but the
recent refactorings to use `Pin<&mut ComponentInstance>` everywhere
makes

Remove `Arc::clone` when creating `LiftContext` (#11253)

A small amount of `unsafe` code is required to enable this but the
recent refactorings to use `Pin<&mut ComponentInstance>` everywhere
makes this a much easier piece of `unsafe` code to verify.

show more ...

implement Component Model async ABI (#11127)

* implement Component Model async ABI

This commit replaces the stub functions and types in
`wasmtime::runtime::component::concurrent` and its submodules

implement Component Model async ABI (#11127)

* implement Component Model async ABI

This commit replaces the stub functions and types in
`wasmtime::runtime::component::concurrent` and its submodules with the working
implementation developed in the `wasip3-prototyping` repo. For ease of review,
it does not include any new tests; I'll add those in a follow-up commit.

Note that this builds on #11123; only the most recent commit is new.

Signed-off-by: Joel Dice <[email protected]>

* clear params pointer in `call_async` when future is dropped

This ensures that the closure we pass to `prepare_call` will never see a stale
pointer.

Note that this could potentially be made more efficient; I'm starting with a
simple solution, and we can refine from there.

Signed-off-by: Joel Dice <[email protected]>

* Remove unsafety from accessing concurrent async state

* Remove a dead variant when async is disabled

* Add tests for `tls.rs` unsafe code

* Refactor `AbortHandle`

* Don't close over the entire future in the `AbortHandle`, instead
change it to just the bare minimum state to manage aborts.
* Move aborting logic into a helper `AbortHandle::run` function which
handles the is-this-aborted-check internally.
* Refactor some logic around spawns how `AbortHandle` is
managed/created.

* Internalize some functions/types

* add FIXME comment to `states.rs`

Signed-off-by: Joel Dice <[email protected]>

* reference issue 11190 in `table.rs` TODO

Signed-off-by: Joel Dice <[email protected]>

* switch `use` directives to conventional syntax

Signed-off-by: Joel Dice <[email protected]>

* remove redundant accessor methods

Signed-off-by: Joel Dice <[email protected]>

* reference issue 11191 in `yield` TODO comments

Signed-off-by: Joel Dice <[email protected]>

* replace `dummy_waker` with `Waker::noop`

Signed-off-by: Joel Dice <[email protected]>

* remove obsolete `AsyncState::spawned_tasks` field

Signed-off-by: Joel Dice <[email protected]>

* only call post-return automatically for `call_concurrent`

This restores the original behavior of requiring explicit post-return calls for
`call[_async]` invocations.

Signed-off-by: Joel Dice <[email protected]>

* Favor function arguments before closures

* Simplify `watch` a bit

Mostly move unnecessary state out of the `Arc`.

* fix task handle leaks and add test coverage

We weren't always disposing of guest or host task handles once they became
unreachable. This adds a couple of hidden methods which integration tests may
use to guard against use-after-delete, double-delete, and leak bugs regarding
waitable handles. It also tightens up handle management in `concurrent.rs` to
ensure those tests pass.

Signed-off-by: Joel Dice <[email protected]>

* Encapsulate type erasure in stream buffers

Don't rely on all buffers to handle `TypeId` and assertions and such,
instead have a helper type which is the one location of the assertions
and everything else can stay typed.

* Remove some methods ending in underscores

* Refactor unsafety in `buffers.rs`

Mostly move away from raw pointers and instead use utilities like
`&[MaybeUninit<T>]`. Also make `WriteBuffer` an `unsafe` trait after
absorbing the `TakeBuffer` trait. Update all safety-related comments
here and there too.

* remove task on drop in `TypedFunc::call_async`

This avoids the need for an `Arc`.

Signed-off-by: Joel Dice <[email protected]>

* remove obsolete clause from `FutureReader::read` docs

Signed-off-by: Joel Dice <[email protected]>

* unhide and expand docs for `WriteBuffer` and `ReadBuffer`

Signed-off-by: Joel Dice <[email protected]>

* add optional `component-model-async-bytes` feature

This gates interop with the `bytes` crate, making it optional and non-default.

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previou

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

This commit enables the `clippy::allow_attributes_without_reason` for
the `wasmtime` crate which previously forcibly allowed it. The reason
this was allowed was that when the workspace was first migrated the
Wasmtime crate had too many instances that I was willing to fix. I've
now come back around and tried to fix everything.

In short: ideally delete `#[allow]`, otherwise use `#[expect]`,
otherwise use `#[allow]`.

prtest:full

* Adjust some directives

* Fix some warnings

* Fix stack switching size tests on unix

* Don't have a conditional `Drop` impl

* Force `testing_freelist` method to be used

Too lazy to write `#[cfg]`, but not too lazy to write a test.

show more ...

update `component-model-async` plumbing (#11123)

* [DO NOT MERGE] update `component-model-async` plumbing

This pulls in the latest Component Model async ABI code from the
`wasip3-prototyping` repo,

update `component-model-async` plumbing (#11123)

* [DO NOT MERGE] update `component-model-async` plumbing

This pulls in the latest Component Model async ABI code from the
`wasip3-prototyping` repo, including various API refactors and spec updates.

This includes all the changes to the `wasmtime` crate from `wasip3-prototyping`
_except_ that the `concurrent` submodule and child submodules contain only
non-functional stubs. For that reason, and the fact that
e.g. `Func::call_async` is now implemented in terms of `Func::call_concurrent`,
most of the component model tests are failing. This commit is not meant to be
merged as-is; a follow-up commit (to be PR'd separately) will contain the real
`concurrent` implementation, at which point the tests will pass again. I'm
splitting these into separate PRs to make review easier.

Signed-off-by: Joel Dice <[email protected]>

* Undo wit-bindgen changes

No longer necessary after other refactors

* Move back to crates.io-based wit-bindgen

* Undo upgrade of http-body-util

(deferred for future PR)

* Add back in arbitrary use of async

Looks like it may have been lost by accident

* Make imports more conventional for Wasmtime

* Some minor changes

* Privatize a component field

* Cut down a bit on #[cfg]

* Undo a no-longer-necessary `pub`

* add doc comments for `{Future,Stream,ErrorContext}Any`

Signed-off-by: Joel Dice <[email protected]>

* rename `concurrent` stub module to `concurrent_disabled`

...and avoid panicking in the stubs.

Signed-off-by: Joel Dice <[email protected]>

* fix test regression

Signed-off-by: Joel Dice <[email protected]>

* revert `call_async` and `post_return_impl` changes

These will need to wait until the `component-model-async` feature is fully
implemented.

Signed-off-by: Joel Dice <[email protected]>

* remove unused struct

Signed-off-by: Joel Dice <[email protected]>

* add `Options::callback` field

This isn't used yet, but will be used when the real `component-model-async`
implementation is merged.

Signed-off-by: Joel Dice <[email protected]>

* Remove no-longer-needed feature

* Trim reexports from Wasmtime

Some of these are no longer needed or can be avoided with small changes.
Some deps are likely needed in the next commit but they'll be best added
there.

* Update test expectations

* More trimming of Cargo.toml

* Defer `*Buffer` traits to next PR

Not needed for this PR I believe.

* Use conventional Wasmtime imports + remove dummy_waker

* Reduce duplication in `*_disabled`

* Remove some unncessary bounds

* Remove some `for<'a>` bounds where unnecessary

* Remove another bound

* Defer more functions to the next PR

`drop_fibers` is different in the next PR, so defer it to then.

* Remove some reexports no longer necessary

Bindings generation changed awhile back so these aren't needed, defer
the implementations to the next PR.

* Remove unnecessary drop

This was already moved to `run_manual_drop_routines`

* Defer a `pub(crate)` to a future PR

* Expand comments in traphandlers

* Defer some types to the next PR

* Update linker documentation

* Add `Send`/`Sync` bounds to `ComponentType`

This commit is extracted from from review of #11123 and #11127. While
not literally present in those PRs it's my own personal conclusion that
it's best to just go ahead and add these bounds at the "base" of the
component trait hierarchy. The current implementation in #11123 adds
bounds in many locations and this would remove the need to add bounds
everywhere and instead have everything inherited through the `Lift` and
`Lower` traits.

This raises the question of: why? The main conclusion that I've reached
leading to this change is that Wasmtime currently will store `R`, a
return value, on the stack during the lowering process back into linear
memory. This might involve allocation, however, meaning that wasm can be
invoked and a context switch could happen. For Wasmtime's `unsafe impl`
of `Send` and `Sync` on fibers to be sound it requires that this
stack-local variable is also `Send` and `Sync` as it's an entirely
user-provided type. Thus I've concluded that for results it's always
required for these to be both `Send` and `Sync` (or at the very least,
`Send`).

Given that I've gone ahead and updated to require both `Send` and `Sync`
for both params and results. This is not expected to actually have any
impact in practice since all primitives are already `Send`/`Sync` (minus
`Rc` impls all removed here) and all `bindgen!`-generated types are
compositions of `Send`/`Sync` primitives meaning that they're also
`Send` and `Sync`.

* Remove some now-unnecessary bounds

* Fix build after #11160

* Remove some now-unnecessary duplicate bounds

* Uncomment test that now works

* Undo accidental doc wrap

* Clarify comment on `Value` types

Don't leave `TODO` in public-facing documentation ideally

* Actually resolve the conflict (forgot to commit)

* Avoid returning boxed futures in APIs

* Defer making constructors more public to a future PR

* Make a method name more conventional

* Refactor `linear_lift_into_from_memory`

* Drop the `max_count` parameter in favor of slicing the `WasmList`
itself. Avoids situations such as what happens if `max_count` is
larger than the length of the list.
* Don't have the default implementation collect to a vector and then
push all that onto a different vector. Instead push each item
individually through `extend`.

* De-indent a block of code added

* Remove unsafety from `prepare_call`

Mostly move the parameters themselves to the closure to avoid raw
pointers/drop/etc.

This will have the consequence of in the future `call_async` is going to
now require `Params: 'static` but that seems more-or-less inevitable at
this point.

* Go back to returning box, alas.

* Apply same treatment to lift function

Make it a closure and reduce some levels of indirection of the various
functions in play.

* Refactor `lower_params` to require less context.

Relax the bounds on the closure specified since it's immediately called
and then additionally take out parameters/captures that the closure can
carry itself.

* Don't pass extraneous `Instance` parameter

This can now be inferred from `Func`.

* Clean up some SAFETY comments

* Generalize the signature of `lift_results`

* Move `lift_results` function to `Func`

Also rename the lift/lower helpers to `with_{lift,lower}_context`

* Remove parameter from `with_lift_context`

Like `with_lower_context` this is fine to capture in the closure passed
in.

* Simplify the dynamic lifting logic

Don't call `with_lift_context` in two locations, only call it once with
a dynamic parameter.

* Refactor away the `Func::lift_results_sync` helper

* Use `with_lift_context` in `call_raw`

* Simplify a call to `Func::call_unchecked_raw`

* Ungate `with_lift_context` to fix non-cm-async build

* Fix compile (bad cherry-pick conflict resolution)

* Use `with_lower_context` in `call_raw`

Trying to unify the async/concurrent paths as much as possible.

* Move params out of `call_raw`

Let closures capture the params, no need to thread it through as an
unnecessary argument.

* Clean up unsafety in `Func::call_raw`

* Accurately mark `call_raw` itself as `unsafe`, then document why
callers should be safe.
* Don't have one large `unsafe` block in `call_raw`, instead split it up
with separate safety comments.

* Move a one-off type definition closer to its use

* Avoid intermediate allocations in dynamic calls

* Simplify a future-return site

* Deduplicate checking parameter count

* Simplify a future invocation with `?`

* Simplify a variable declaration

* Simplify some function signatures

* Remove outdated safety comment

* Refactor to not require `Params: 'static` on `call_async`

* Remove no-longer-necessary SAFETY comment

* Fix typos

* Add a fast-path with no `Box` for sync host functions

Speeds up host calls by ~20% and puts them back on parity with the
beforehand numbers Wasmtime has.

* Synchronize signatures of async/concurrent dynamic calls

Use slices for both instead of vecs for one and slices for the other.
Required some slight rejiggering. Apparently one can solve a closure
problem with another closure, then one surely has no more closure
problems.

* Fix non-cm-async build

---------

Signed-off-by: Joel Dice <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...

Remove hash tables and bump chunk from the DRC collector (#11175)

* Remove hash tables and bump chunk from the DRC collector

This removes the explicit `HashSet`s used to represent the
over-approxim

Remove hash tables and bump chunk from the DRC collector (#11175)

* Remove hash tables and bump chunk from the DRC collector

This removes the explicit `HashSet`s used to represent the
over-approximated-stack-roots and precise-stack-roots sets and replaces them
with an intrusive, singly-linked list and a mark bit in the object headers
respectively. The new list implementation also subsumes the old bump chunk that
sat in front of the old over-approximated-stack-roots hash set.

This shaves off about 25% of the time it takes to run the test case in
https://github.com/bytecodealliance/wasmtime/issues/11141 for me locally.

This also ended up being a nice simplification of the DRC collector, which in
turn allowed us to further simplify the `GcHeap` trait, since we no longer ever
need to GC before passing GC refs into Wasm.

Fixes https://github.com/bytecodealliance/wasmtime/issues/11162

* Reorder memory operations when pushing onto the over-approximated-stack-roots list

* Address some more review feedback

* More review feedback

* Fix endianness issue with loading reserved bits

* Update disas tests after endianness fix

show more ...

Use `Pin<&mut ComponentInstance>` (#11042)

This commit is the continuation of #10943 for component instances. The
allocation/vmctx infrastructure was additionally refactored to be shared for
both co

Use `Pin<&mut ComponentInstance>` (#11042)

This commit is the continuation of #10943 for component instances. The
allocation/vmctx infrastructure was additionally refactored to be shared for
both core and component instances since they behave the exact same way anyway.
This further enables sharing various methods like `vmctx_plus_offset` which are
pretty unsafe internally.

Like #10943 this necessitated removal of `Index` implementations because
`IndexMut` is not compatible with the returned type being `Pin<&mut T>`
so they were replaced by inherent `get` and `get_mut` methods on the
component instance id type.

Closes #10933

show more ...

Execute component lifts/lowers with Miri (#11006)

* Execute component lifts/lowers with Miri

Historically nothing related to components has been able to run through
Miri due to the limitation that

Execute component lifts/lowers with Miri (#11006)

* Execute component lifts/lowers with Miri

Historically nothing related to components has been able to run through
Miri due to the limitation that components, unlike core wasm, require
compiled wasm code to call between the host and the guest. With the
advent of Pulley, however, this has changed! We already have a test
that's run specifically on CI which precompiles a wasm module on the
host and then uses the `*.cwasm` in Miri, so this does the same for
components.

This adds a new test which instantiates a component and then runs
lifts/lowers for some basic types with the static and dynamic host APIs.
This is intended to weed out a large class of possible soundness issues
but doesn't touch on all the unsafe code that we have at this time.
Nevertheless there's a lot more run through Miri than before and a few
minor locations were fixed up as a result. The hope is that this can
serve as a basis for extending the set of component tests in Miri over
time.

* Expose provenance of all builtins too

* Fix warnings

show more ...

Start reducing unsafety of `ComponentInstance` (#10934)

Work recently in the wasip3-prototyping repository has focused on
reducing the amount of `unsafe` code and improving internal abstractions
to

Start reducing unsafety of `ComponentInstance` (#10934)

Work recently in the wasip3-prototyping repository has focused on
reducing the amount of `unsafe` code and improving internal abstractions
to facilitate this. One major thrust that's manifested in is the removal
of the usage of `*mut ComponentInstance` where possible and instead
using an index to safely borrow from the store to get the entire
instance. This commit does not fully realize this vision just yet but
lays some groundwork leading up to this.

This commit specifically removes the `*mut ComponentInstance` pointers
in lift/lower contexts in favor of directly storing a
`wasmtime::component::Instance`. When the raw `ComponentInstance` is
needed it's acquired from the `StoreOpaque` in a safe fashion that
borrows the entire store for the duration of the returned borrow. This
in turn required pushing instances into the store earlier during
instantiation because during instantiation an instance could call out to
host APIs which do lifts/lowers.

There's still more work to be done to plumb this fully into libcalls and
host function invocations but I wanted to upstream the wasip3 work
piecemeal a chunk at a time.

show more ...

Remove `Stored` usage from `wasmtime::component::Instance` (#10913)

* Remove mutability required on a number of component methods

Powered by previous refactorings it's possible to just take
`&Store

Remove `Stored` usage from `wasmtime::component::Instance` (#10913)

* Remove mutability required on a number of component methods

Powered by previous refactorings it's possible to just take
`&StoreOpaque` in these locations.

* Move core instance map into `ComponentInstance`

This commit moves the mapping from a `RuntimeInstanceIndex` to a
`wasmtime::Instance` from `wasmtime::component::InstanceData` into the
internal `ComponentInstance` structure. This is done in preparation to
remove `InstanceData` eventually.

* Move `Component` to live in `ComponentInstance`

Previously this lived in `InstanceData` but that's just a historical
artifact of the old `wasmtime` and `wasmtime-runtime` split. Nowadays
it's possible to store `Component` directly to further move information
out of `InstanceData`.

* Move `InstanceData::imports` to `ComponentInstance`

More preparation for the removal of `InstanceData` entirely.

* Move lookup functions from `InstanceData` to `ComponentInstance`

More prep for the removal of `InstanceData`.

* Reduce some more reliance on `InstanceState`

Just removing it from some type signatures to make future removal
easier.

* Remove an unused result from a helper function

No caller needs it, so go ahead and remove it.

* Make `ComponentInstance::imports` private

This moves some methods around and documents preexisting `unsafe`
contracts to get this field private and prevent external access to it.

* Remove `InstanceData` from `Instantiator`.

Use `OwnedComponentInstance` instead.

* Remove `InstanceData`, refactor `Instance`

This commit refactors the representation of `component::Instance` to be
purely index-based to data already within a store. This makes creation
of an `Instance` free compared to before where auxiliary data needed to
be created. Note that this doesn't actually change storage within a
`Store<T>` as instances are still there, it's just that now the storage
lives in a non-`Stored`-related location.

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