Remove some more panics in `concurrent.rs` (#12874)

Downgrade some panics to `bail_bug!` or `?` where appropriate by
propagating `Result<T>` in a few more locations.

Enable limiting wasip3 resource limits (#12761)

* Enable limiting wasip3 resource limits

This commit adds a new `Store::concurrent_resource_table` method which
enables getting a handle to the under

Enable limiting wasip3 resource limits (#12761)

* Enable limiting wasip3 resource limits

This commit adds a new `Store::concurrent_resource_table` method which
enables getting a handle to the underlying `ResourceTable` used by the
concurrent implementation of component-model-async. This can in turn be
used to set the max capacity on the table and limit the guest usage of
the table.

Closes #11552

* Adjust features

* Fix imports

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

Consolidate component-related store data (#12549)

Instead of having `#[cfg]` within `store.rs` move it all to
`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in some
places trying t

Consolidate component-related store data (#12549)

Instead of having `#[cfg]` within `store.rs` move it all to
`component/store.rs` to cut down on `#[cfg]`. It's a bit awkward in some
places trying to borrow a bunch of fields at once, but it's not the end
of the world.

show more ...

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

* deprecate `[Typed]Func::post_return[_async]` and make them no-ops

With the advent of the Component Model concurrency ABI

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

* deprecate `[Typed]Func::post_return[_async]` and make them no-ops

With the advent of the Component Model concurrency ABI and it's `task.return`
intrinsic, post-return functions have been informally deprecated and are
expected to be removed for WASI 1.0 and the corresponding stable edition of the
Component Model. Consequently, it does not make sense anymore to require
embedders to explicitly call the post-return function after using
`[Typed]Func::call[_async]`.

As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, the
post-return function is called automatically as part of
`[Typed]Func::call[_async]` if present, which is how
`[Typed]Func::call_concurrent` has worked all along. In addition, this commit
fixes and tests a couple of cases where the task and/or thread was being
disposed of before the post-return function was called.

* address review feedback

* test post-return function in more scenarios

Specifically, I've split the `invoke_post_return` test into multiple tests:

- using `TypedFunc::call`
- using `TypedFunc::call_async` with concurrency support enabled
- using `TypedFunc::call_async` with concurrency support disabled
- using `Func::call_async` with concurrency support disabled
- using `TypedFunc::call_concurrent`

* remove GCC/clang-specific deprecation attribute

This broke the MSVC build.

* bless bindgen output

* remove obsolete post-return functions and fields

Now that post-return calls are handled internally without requiring explicit
action by the embedder, we can avoid unnecessary bookkeeping.

show more ...

Refactor how concurrency support is enabled in a `Store` (#12416)

* Document panics from using CM async machinery when CM async is not enabled

* Refactor how concurrency support is enabled in a `St

Refactor how concurrency support is enabled in a `Store` (#12416)

* Document panics from using CM async machinery when CM async is not enabled

* Refactor how concurrency support is enabled in a `Store`

This commit is an extension/refactor of #12377 and #12379. Notably this
decouples the runtime behavior of Wasmtime from enabled/disabled
WebAssembly proposals. This enables the `wasmtime serve` subcommand, for
example, to continue to disallow component-model-async by default but
continue to use `*_concurrent` under the hood.

Specifically a new `Config::concurrency_support` knob is added. This is
plumbed directly through to `Tunables` and takes over the preexisting
`component_model_concurrency` field. This field configures whether
tasks/etc are enabled at runtime for component-y things. The default
value of this configuration option is the same as `cfg!(feature =
"component-model-async")`, and this field is required if
component-model-async wasm proposals are enabled. It's intended that
eventually this'll affect on-by-default wasm features in Wasmtime
depending if the support is compiled in.

This results in a subtle shift in behavior where component-model-async
concurrency is used by default now because the feature is turned on by
default, even though the wasm features are off-by-default. This required
adjusting a few indices expected in runtime tests due to tasks/threads
being allocated in index spaces.

Finally, this additionally denies access at runtime to
`Linker::*_concurrent` when concurrent support is disabled as otherwise
the various runtime data structures won't be initialized and panics will
happen.

Closes #12393

* Add a `-Wconcurrency-support` CLI flag

Used to update disas tests to show that, when disabled, old codegen
quality is preserved

* Ungate `Config` flag

* Review comments

---------

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

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

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implem

Debug: create private code memories per store when debugging is enabled. (#12051)

* Debug: create private code memories per store when debugging is enabled.

This will allow patching code to implement e.g. breakpoints. (That is,
for now the copies are redundant, but soon they will not be.)

This change follows the discussion [here] and offline to define a few
types that better encapsulate the distinction we want to enforce.
Basically, there is almost never a bare `CodeMemory`; they are always
wrapped in an `EngineCode` or `StoreCode`, the latter being a per-store
instance of the former. Accessors are moved to the relevant place so
that, for example, one cannot get a pointer to a Wasm function's body
without being in the context of a `Store` where the containing module
has been registered. The registry then returns a `ModuleWithCode` that
boxes up a `Module` reference and `StoreCode` together for cases where
we need both the metadata from the module and the raw code to derive
something.

The only case where we return raw code pointers to the `EngineCode`
directly have to do with Wasm-to-array trampolines: in some cases, e.g.
`InstancePre` pre-creating data structures with references to host
functions, it breaks our expected performance characteristics to make
the function pointers store-specific. This is fine as long as the
Wasm-to-array trampolines never bake in direct calls to Wasm functions;
the strong invariant is that Wasm functions never execute from
`EngineCode` directly. Some parts of the component runtime would also
have to be substantially refactored if we wanted to do away with this
exception.

The per-`Store` module registry is substantially refactored in this PR.
I got rid of the modules-without-code distinction (the case where a
module only has trampolines and no defined functions still works fine),
and organized the BTreeMaps to key on start address rather than end
address, which I find a little more intuitive (one then queries with the
dual to the range -- 0-up-to-PC and last entry found).

[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812

* Review feedback: do not assume a reasonable code alignment; error when it cannot be known

* Review feedback: fail properly in profiler when we are cloning code

* Fix guest-profiler C API.

* Review feedback: make private-code representation impossible in non-debugging-support builds.

* Add TODO comment referencing issue for cloning only .text.

* clang-format

* Review feedback: add back Component::image_range.

* Review feedback: error on registering profiling metadata when debug is enabled.

* rustfmt

* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out.

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

Delete `StoreOpaque::traitobj_mut` (#11444)

* Delete `StoreOpaque::traitobj_mut`

This was a fundamentally unsound function because it is widening a
mutable borrow to encompass more than it original

Delete `StoreOpaque::traitobj_mut` (#11444)

* Delete `StoreOpaque::traitobj_mut`

This was a fundamentally unsound function because it is widening a
mutable borrow to encompass more than it originally contained. Removal
of its usage falls into a few buckets here:

* Many instances of `store.0.traitobj_mut()` were starting from a
`&mut StoreInner<T>`, going to `&mut StoreOpaque`, then going back to
`&mut dyn VMStore`. These are replaced with `store.0` as
`&mut StoreInner<T>` directly coerces into `&mut dyn VMStore`.

* Some fiber-related helpers were updated to take any store-opaque-thing
which encapsulates the ability to start/resume a borrow with a part of
the store, but you only get that part of the store during the fiber
itself. This means there's no widening necessary.

* Some methods previously taking `&mut StoreOpaque` are now
appropriately widened to `&mut dyn VMStore`.

This all enables full deletion of this function which prevents
accidentally ever tripping over its unsound-ness.

* Fix configured build

* Another fix for a configured build

* Fix a warning

* Don't hold `VMStore` live over await points

* Review comments

* Move `AsStoreOpaque` to `store.rs` and use it in GC

* Fix configured build

* Switch lint annotation

show more ...

refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)

* refactor `{Stream,Future}|{Reader,Writer}` APIs and internals

This makes a several changes to how `{Stream,Future}|{Reader,W

refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)

* refactor `{Stream,Future}|{Reader,Writer}` APIs and internals

This makes a several changes to how `{Stream,Future}|{Reader,Writer}` work to
make them more efficient and, in some ways, more ergonomic:

- The background tasks have been removed, allowing reads and writes to complete without task context switching. We now only allocate and use oneshot channels lazily when the other end is not yet ready; this improves real world performance benchmarks (e.g. wasi-http request handling) considerably.

- Instances of `{Stream,Future}Reader` can now be lifted and lowered directly; no need for `Host{Stream,Future}` anymore.

- The type parameter for `Stream{Reader,Writer}` no longer refers to the buffer type -- just the payload type (i.e. `StreamReader<u8>` instead of `StreamReader<Vec<u8>>`), meaning any buffer type may be used for a given read or write operation. This also means the compiler needs help with type inference less often when calling `Instance::stream`.

- Instances of `{Stream,Future}|{Reader,Writer}` now require access to the store in order to be disposed of properly. I've added RAII wrapper structs (`WithAccessor[AndValue]`) to help with this, and also updated `Store::drop` and `Instance::run_concurrent` to ensure the store thread-local is set when dropping futures closing over `&Accessor`s.

- In order to ensure that resources containing `{Stream,Future}|{Reader,Writer}` instances are disposed of properly, I've added `LinkerInstance::resource_concurrent` and have updated `wasmtime-wit-bindgen` to use it. This gives resource drop functions access to a `StoreContextMut` via an `Accessor`, allowing the stream and future handles to be disposed of.
- In order to make this work, I had to change `Accessor::instance` from a `Instance` to an `Option<Instance>`, which is awkward but temporary since we're planning to remove `Accessor::instance` entirely once we've moved concurrent state from `ComponentInstance` to `Store`.

That problem of disposal is definitely the most awkward part of all this. In
simple cases, it's easy enough to ensure that read and write handles are
disposed of properly, but both `wasmtime-wasi` and `wasmtime-wasi-http` have
some pretty complicated functions where handles are passed between tasks and/or
stored inside resources, so it can be tricky to ensure proper disposal on all
code paths. I'm open to ideas for improving this, but I suspect we'll need new
Rust language features (e.g. linear types) to make it truly ergonomic, robust,
and efficient.

While testing the above, I discovered an issue with `Instance::poll_until` such
that it would prematurely give up and return a "deadlock" trap error, believing
that there was no further work to do, even though the future passed to it was
ready to resolve the next time it was polled. I've fixed this by polling it one
last time and only trapping if it returns pending.

Note that I've moved a few associated functions from `ConcurrentState` to
`Instance` (e.g. `guest_drop_writable` and others) since they now need access to
the store; they're unchanged otherwise. Apologies for the diff noise.

Finally, I've tweaked how `wasmtime serve` to poll the guest for content before
handing the response to Hyper, which helps performance by ensuring the first
content chunk can be sent with the same TCP packet as the beginning of the
response.

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

fix wasi p3 build and test failures

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

use `ManuallyDrop` instead of `Option` in `Dropper`

This allows us to drop its `value` field in-place, i.e. without moving it,
thereby upholding the `Pin` guarantee.

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

address review comments

- Remove `DropWithStoreAndValue` and friends; go back to taking a `fn() -> T` parameter in `Instance::future` instead
- Make `DropWithStore::drop[_with]` take `&mut self` instead of `self`
- Make `WithAccessor` and `DropWithStore` private
- Instead, I've added public `Guarded{Stream,Future}{Reader,Writer}` types for RAII
- and also `{Stream,Future}{Reader,Writer}::close[_with]` methods
- Use RAII in `FutureReader::read` and `FutureWriter::write` to ensure handles are dropped if the `Future` is dropped

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

* lower host stream/future writes in background task

This avoids unsoundness due to guest realloc calls while there are host embedder
frames on the stack.

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

* fix `tcp.rs` regressions

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

---------

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

show more ...

Gut `vm::Export` to mostly be `crate::Extern` (#11229)

* Remove `Table::from_wasmtime_table`

This commit removes the unsafe function `Table::from_wasmtime_table`.
This goes a bit further and remove

Gut `vm::Export` to mostly be `crate::Extern` (#11229)

* Remove `Table::from_wasmtime_table`

This commit removes the unsafe function `Table::from_wasmtime_table`.
This goes a bit further and removes `ExportTable` entirely as well which
means that table lookup on a `vm::Instance` directly returns a
`wasmtime::Table` without any need to translate back-and-forth.

* Remove `Tag::from_wasmtime_tag`

Like the previous commit, but for tags.

* Remove `Global::from_wasmtime_global`

Like the previous commit, but for globals.

* Remove `Memory::from_wasmtime_memory`

Like the previous commit, but for memories.

* Remove `Func::from_wasmtime_function`

Like previous commits, but for functions.

* Fix lints

* Fill out missing safety comment

* Review comments

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

generalize async fiber abstraction (#11114)

* generalize async fiber abstraction

As part of the work implementing the new Component Model async ABI in the
`wasip3-prototyping` repo, I've generalize

generalize async fiber abstraction (#11114)

* generalize async fiber abstraction

As part of the work implementing the new Component Model async ABI in the
`wasip3-prototyping` repo, I've generalized the `FiberFuture` abstraction in
`wasmtime::runtime::store::async_` to support fibers which can either retain
exclusive access to the store across suspend points or release it. The latter
allows the store to be used by the `component-model-async` event loop and/or
other fibers to run before the original fiber resumes, which is the key to
allowing multiple fibers to run concurrently, passing control of the store back
and forth.

In the case of Pulley, the above generalization means we also need to give each
fiber its own `Interpreter` so that multiple concurrent fibers don't clobber
each other's state.

Concretely, this moves a lot of the code out of `async_.rs` and into a new
`fiber.rs` submodule which will be shared with the `component-model-async`
implementation.

This also pulls in a new `StoreToken<T>` utility which has been useful in
`wasip3-prototyping` to safely convert from a `&mut dyn VMStore` to a
`StoreContextMut<'a, T>` when we previously witnessed a conversion in the other
direction.

Note that I've added a `'static` bound to the `VMStore` trait, which simplifies
use of `&mut dyn VMStore`, avoiding thorny lifetime issues.

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

* address review feedback

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

* fix miri-flagged stacked borrow violation

As part of my earlier effort to unify the fiber abstractions in the `wasmtime`
crate, I changed a `*mut StoreFiber` field to a `&mut StoreFiber`, not realizing
that it resulted in a mutable alias at runtime and thus undefined behavior.
Miri caught it, fortunately.

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

* remove unneeded `Send` bounds

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

* address more review feedback

Main changes:

- Make `resume_fiber[_raw]` take a `&mut StoreOpaque` parameter to make its unsafe internals easier to reason about, safety-wise.

- Panic if `StoreFiber::drop` is called on an in-progress fiber without having called `StoreFiber::dispose` to gracefully end it first.

- (Re)introduce `FiberFuture`, which closes over a `&mut StoreOpaque` and uses it to call `StoreFiber::dispose` on drop.

This will require a few more changes to make it usable by `concurrent.rs`, but
I'll save those changes for a later PR.

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

* address more review feedback

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

* update `impl Send For StoreFiber` comment

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

* Remove currently-extraneous `Result<()>` from fibers

May be needed for concurrent bits, but for now not necessary.

* Use safe pointers instead of raw pointers

It's predicted Miri won't like this, but for now in-repo it's ok with it.

* Fold more responsibility into `resume_fiber_raw`

Remove the need for the function entirely and replace it with
`resume_fiber`.

* Remove channels from async fibers

Can use stack-based closures/results to transmit the result instead of
needing a channel.

* Fold `on_fiber_raw` directly into `on_fiber`

The `on_fiber` function is small enough it should be possible to do so.

* Don't use `Option` in `FiberFuture`

Leave the fiber non-optional at-rest so it's always available for the
destructor.

* Fold `suspend` functions together

Small shims, not otherwise public at this time, so remove a layer of
indirection.

* Move stack limit management to `FiberResumeState`

Helps remove some raw pointers that are held for a long time within
`AsyncCx`

* add some doc comments to `fiber.rs`

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

* update `fiber.rs` and friends to match CM async requirements

This adds a `resolve_or_release` function, which `Instance::resume_fiber` will
use when current `concurrent.rs` stub is replaced by a real implementation.

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

* fix non-component-model-async build warnings

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

* make `resume_fiber` private in `fiber.rs`

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

* Shrink `PollContext` state

Move management of the async guard range elsewhere to the normal
save/restore area.

* Refactor `AsyncCx`, reduce `unsafe`

* Remove the `AsyncCx` type from Wasmtime as it's inherently `unsafe` to
use, instead bundle operations directly on a `Store*` reference.

* Don't retain pointers-to-pointers within the roughly-equivalent
`BlockingContext` created in this PR. Instead when a blocking context
is created "take" the metadata from the store to assert exclusive
ownership of the pointers.

* Refactor how `&mut Context<'_>` is passed around, namely thread it
through fiber parameters to model resumption as registering a new
context to poll with.

* Remove `PollContext` in favor of directly storing a pointer as it's
now mostly an empty structure.

* Minor refactorings to make things more future-refactorable and/or
clear in a few places.

* Refactor management of the "current suspend" and "current future
context" pointers. These are now null'd out on resumption and asserted
null on suspension.

* Remove the need for a generic `Reset` structure in the fiber bits as
it's a pretty dangerous structure to have in general.

The end result of this refactoring is that all usage of `block_on` is
now safe and additionally many of the internals of the implementation
are safer than they were before

* Adjust some lint attributes

* Make manipulation of `AsyncState` safe

No need for raw pointers with recent refactorings.

* Fix dead code warning

* More dead code warnings

* Cut down on raw pointers in fiber.rs

* Move executor save/restore to normal fiber state save/restore

* Bikeshed a method name

* update comment in make_fiber

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

* fix machports build

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

---------

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

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

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

Change component/instance maps to `PrimaryMap` (#10916)

* Change component/instance maps to `PrimaryMap`

This switches to using typed keys for these maps to be more idiomatic
with the rest of Wasmt

Change component/instance maps to `PrimaryMap` (#10916)

* Change component/instance maps to `PrimaryMap`

This switches to using typed keys for these maps to be more idiomatic
with the rest of Wasmtime and this has the additional benefit of
compressing indices to 32-bits instead of the previous
pointer-sized-bits.

* Fix an unused import

show more ...

Refactor the representation of component::Func (#10914)

* Expand on FIXME comments

In case it takes awhile to get to them...

* Remove `FuncData::types`

This can always be inferred from the insta

Refactor the representation of component::Func (#10914)

* Expand on FIXME comments

In case it takes awhile to get to them...

* Remove `FuncData::types`

This can always be inferred from the instance itself.

* Add an `ExportIndex` to `FuncData`

This will soon be used to remove most other fields, but for now just
have it hanging out there.

* Remove `FuncData::component_instance` field

* Remove `FuncData::post_return`

* Remove `FuncData::ty`

* Remove `FuncData::export`

* Remove `FuncData::options`

* Remove `FuncData::post_return_arg`

This field was moved to `ComponentInstance` as the stateful storage of
the last function return value.

* Refactor the representation of `component::Func`

This commit updates the implementation of `component::Func` to be
index-based like all other exported items are now in Wasmtime. This
necessitated a new `StoreComponentInstanceId` abstraction similar to
`StoreInstanceId`. Additionally the `component_instance_replace`
function was entirely removed as it's no longer necessary.

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

Refactor globals to no longer use `Stored` (#10902)

This commit refactors the `wasmtime::Global` to avoid the usage of
`Stored<T>` internally. This makes conversion from internal global state
to ext

Refactor globals to no longer use `Stored` (#10902)

This commit refactors the `wasmtime::Global` to avoid the usage of
`Stored<T>` internally. This makes conversion from internal global state
to external global state a noop along the lines of previous commits. The
end goal is to remove `Stored` entirely and enable more pervasively using
external types internally within Wasmtime as well.

Globals were different than the prior iterations of memories, tags, and
tables. Globals have three different ways of defining them: wasm
instances, the host embedder, and component flags. Representing these
in all the various locations required a bit of finesse in how everything
is represented and stored at rest and such. In the end there's a small
amount of "type punning" in a few instance/vmctx fields related to
globals now since everything is squeezed into one slot. This is required
because the `VMGlobalImport` structure must have a size known to
wasm-compiled code and `wasmtime::Global` must have a known layout for C
code.

In the end while this is more code to manage globals my hope is that the
end result will be a net negative in terms of complexity by ensuring
that the embedder API is additionally suitable for use internally within
Wasmtime as well.

show more ...

Add a new `ComponentInstanceId` type (#10896)

This is intended to be similar to `InstanceId`, but used for components.

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTF

Add support for `#![no_std]` to the `wasmtime` crate (#8533)

* Always fall back to custom platform for Wasmtime

This commit updates Wasmtime's platform support to no longer require an
opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming
officially supported this should provide a better onboarding experience
where the fallback custom platform is used. This will cause linker
errors if the symbols aren't implemented and searching/googling should
lead back to our docs/repo (eventually, hopefully).

* Change Wasmtime's TLS state to a single pointer

This commit updates the management of TLS to rely on just a single
pointer rather than a pair of a pointer and a `bool`. Additionally
management of the TLS state is pushed into platform-specific modules to
enable different means of managing it, namely the "custom" platform now
has a C function required to implement TLS state for Wasmtime.

* Delay conversion to `Instant` in atomic intrinsics

The `Duration` type is available in `no_std` but the `Instant` type is
not. The intention is to only support the `threads` proposal if `std` is
active but to assist with this split push the `Duration` further into
Wasmtime to avoid using a type that can't be mentioned in `no_std`.

* Gate more parts of Wasmtime on the `profiling` feature

Move `serde_json` to an optional dependency and gate the guest profiler
entirely on the `profiling` feature.

* Refactor conversion to `anyhow::Error` in `wasmtime-environ`

Have a dedicated trait for consuming `self` in addition to a
`Result`-friendly trait.

* Gate `gimli` in Wasmtime on `addr2line`

Cut down the dependency list if `addr2line` isn't enabled since then
the dependency is not used. While here additionally lift the version
requirement for `addr2line` up to the workspace level.

* Update `bindgen!` to have `no_std`-compatible output

Pull most types from Wasmtime's `__internal` module as the source of
truth.

* Use an `Option` for `gc_store` instead of `OnceCell`

No need for synchronization here when mutability is already available in
the necessary contexts.

* Enable embedder-defined host feature detection

* Add `#![no_std]` support to the `wasmtime` crate

This commit enables compiling the `runtime`, `gc`, and `component-model`
features of the `wasmtime` crate on targets that do not have `std`. This
tags the crate as `#![no_std]` and then updates everything internally to
import from `core` or `alloc` and adapt for the various idioms. This
ended up requiring some relatively extensive changes, but nothing too
too bad in the grand scheme of things.

* Require `std` for the perfmap profiling agent

prtest:full

* Fix build on wasm

* Fix windows build

* Remove unused import

* Fix Windows/Unix build without `std` feature

* Fix some doc links

* Remove unused import

* Fix build of wasi-common in isolation

* Fix no_std build on macos

* Re-fix build

* Fix standalone build of wasmtime-cli-flags

* Resolve a merge conflict

* Review comments

* Remove unused import

show more ...

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be u

Support compilation-only build by adding a `runtime` feature (#7766)

* Add `runtime` feature to `wasmtime` crate

This feature can be disabled to build `wasmtime` only for compilation.
This can be useful when cross-compiling, especially on a target that
can't run wasmtime itself (e.g. `wasm32`).

* prtest:full

* don't round pages without runtime feature

* fix async assertions

* move profiling into runtime

* enable runtime for wasmtime-wasi

* enable runtime for c-api

* fix build_artifacts in non-cache case

* fix miri extensions

* enable runtime for wast

* enable runtime for explorer

* support cranelift all-arch on wasm32

* add doc links for `WeakEngine`

* simplify lib runtime cfgs

* move limits and resources to runtime

* move stack to runtime

* move coredump and debug to runtime

* add runtime to coredump and async features

* add wasm32 build job

* combine engine modules

* single compile mod

* remove allow for macro paths

* add comments

show more ...