winch: implement ref.null, ref.is_null, ref.func, and typed select (#12940)

* winch: implement ref.null, ref.is_null, ref.func, and typed select

* add disas tests and ref.func call_indirect coverag

winch: implement ref.null, ref.is_null, ref.func, and typed select (#12940)

* winch: implement ref.null, ref.is_null, ref.func, and typed select

* add disas tests and ref.func call_indirect coverage

* register wasmtime module in fuzz wast_test to fix wast_smoke_test

show more ...

Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)

* Exceptions: add exception-specific (command-sequence) fuzzer.

This fuzzer uses a description of a set of "scenarios", arbitr

Exceptions: add exception-specific (command-sequence) fuzzer. (#12923)

* Exceptions: add exception-specific (command-sequence) fuzzer.

This fuzzer uses a description of a set of "scenarios", arbitrarily
generated, to produce a specific kind of module that tests throw/catch
behavior. The module contains a chain of functions that invoke each
other; one will throw, and the rest may have catch clauses that do or
do not catch.

* Review feedback.

show more ...

PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built

PCC: remove proof-carrying code (for now?). (#12800)

In late 2023, we built out an experimental feature called
Proof-Carrying Code (PCC), where we attached "facts" to values in the
CLIF IR and built verification of these facts after lowering to
machine instructions. We also added "memory types" describing layout
of memory and a "checked" flag on memory operations such that we could
verify that any checked memory operation accessed valid memory (as
defined by memory types attached to pointer values via
facts). Wasmtime's Cranelift backend then put appropriate memory types
and facts in its IR such that all accesses to memory (aspirationally)
could be checked, taking the whole mid-end and lowering backend of
Cranelift out of the trusted core that enforces SFI.

This basically worked, at the time, for static memories; but never for
dynamic memories, and then work on the feature lost
prioritization (aka I had to work on other things) and I wasn't able
to complete it and put it in fuzzing/enable it as a production option.

Unfortunately since then it has bit-rotted significantly -- as we add
new backend optimizations and instruction lowerings we haven't kept
the PCC framework up to date.

Inspired by the discussion in #12497 I think it's time to delete
it (hopefully just "for now"?) unless/until we can build it again. And
when we do that, we should probably get it to the point of validating
robust operation on all combinations of memory configurations before
merging. (That implies a big experiment branch rather than a bunch of
eager PRs in-tree, but so it goes.) I still believe it is possible to
build this (and I have ideas on how to do it!) but not right now.

show more ...

Clean up `gc_ops` fuzzing mutator (#12533)

* Clean up `gc_ops` fuzzing mutator

This commit cleans up a few random things about the `gc_ops` fuzzing mutator,
notably:

* The macro to define `GcOp` a

Clean up `gc_ops` fuzzing mutator (#12533)

* Clean up `gc_ops` fuzzing mutator

This commit cleans up a few random things about the `gc_ops` fuzzing mutator,
notably:

* The macro to define `GcOp` and many of its methods is refactored to be more
extensible going forward (e.g. all of GC op `fixup` is now macro-generated,
instead of having special-cases for typed struct ops, and we could probably
also move encoding into the macro as a follow up PR).
* Furthermore, the macro is also a `for_each_*`-style macro now, which lets us
define the GC ops once and then use the macro multiple times to define
different things, rather than being forced to put everything we want to
generate into one macro RHS. This should make things a bit easier to read and
edit and plays nicer with LSP.
* A bunch of GC op filtering that was logically part of fixing up an instruction
is now actually part of `GcOp::fixup`. Also a redundant `op.fixup()` call was
removed, `GcOp::fixup` takes `&self` instead of `&mut self` since it returns a
new `GcOp` now instead of mutatint `self` in place, etc...
* A few other small things here and there.

* Fix `GcOps` fuzz mutator tests

Also remove the `test_wat_string` test because it isn't really helpful at this
point, it is just something we have to remember to update whenever we
add/remove/change `GcOp`s while not giving us anything in return.

show more ...

Struct locals etc (#12513)

* Add structref local/global/table access for structs

* The number of iters back to 2048

* Remove forgotten struct_num_local from limits

* Address initial reviews

* Id

Struct locals etc (#12513)

* Add structref local/global/table access for structs

* The number of iters back to 2048

* Remove forgotten struct_num_local from limits

* Address initial reviews

* Idiomatic comments

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

Migrate fuzzing to `wasmtime::error` (#12263)

* Migrate fuzzing to `wasmtime::error`

* fix

Add a new fuzzer focused on component-model-async events (#12119)

* Add a new fuzzer focused on component-model-async events

This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime
whic

Add a new fuzzer focused on component-model-async events (#12119)

* Add a new fuzzer focused on component-model-async events

This commit adds a new fuzzer mode to the `misc` fuzzer of Wasmtime
which is focused on async events and interleavings of components using
the component-model-async proposal. This fuzzer works by having a
precompiled guest program which serves as the component to run. This
precompiled component has a custom `fuzz.wit` which is used to interface
with the fuzzer itself. The fuzzer is then a fuzz-generated sequence of
commands to send to the component which verifies that everything
executes correctly, has no panics, etc.

This fuzzer intends to stress async communication and task
infrastructure with component-model-async. Notably this does not stress
lifting/lowering or arbitrary type signatures. This does, however,
permute all of the following:

* Guest/host interactions (also guest/guest, host/host, etc).
* Async functions, both ready and pending.
* Future operations: reads, writes, cancellation, transfers, etc.
* Stream operations: reads, writes, cancellation, transfers, etc.

This is all throwing into a large "soup" and then asserted to work
correctly. There's a few gotchas here and there for how this fuzzer is
designed, such as some events requiring "yield N times to await this
event happening". This is required because Wasmtime is allowed to
non-deterministically select between a number of "ready events" and what
to dispatch.

This is not intended to be a one-size-fits-all fuzzer for
component-model-async. The recent enhancements to the `component_api`
fuzzer are intended to complement this fuzzer in terms of what's
stressed where internally.

* Review comments

show more ...

"Downgrade" threads support to tier 2, disable fuzzing (#12036)

* "Downgrade" threads support to tier 2, disable fuzzing

This commit is borne out of a fuzz bug that was opened recently. The
fuzz bu

"Downgrade" threads support to tier 2, disable fuzzing (#12036)

* "Downgrade" threads support to tier 2, disable fuzzing

This commit is borne out of a fuzz bug that was opened recently. The
fuzz bug specifically has to do with fallout from #12022, specifically
`SharedMemory` being used to allocated instead of `Memory`. In this
situation the resource limiter is no longer consulted meaning that
shared memories bypass this and aren't caught by OOM checks. This is
currently by design because `SharedMemory` instances don't know which
resource limiter to hook into per-store.

More generally though the implementation of wasm threads, while workable
in Wasmtime, has a number of known relatively large deficiencies. These
were not resolved prior to ungating the wasm proposal (that's on me) but
nevertheless the quality of implementation is not quite up to "tier 1
par" with the rest of what Wasmtime offers. Given this the threads
proposal is now downgraded to tier 2. To help minimize the impact of
this the wasm proposal is left enabled-by-default, but creation of a
`SharedMemory` in the Rust API requires opting-in via a new
`Config::shared_memory` method.

This commit shuffles around some documentation of wasm proposals to
split it into tier 1/2/3 instead of on/off-by-default and then adds a
column for whether the proposal is on-by-default.

* clangformat

* Fix tests

* Add tests for failed creation

Fix an issue where defined shared memories weren't gated

* Sync disabled threads stub

* Fix another test

prtest:full

* Fix fuzzing tests

* Fix dwarf tests

show more ...

Improve `Config`-related coverage of `component_api` (#12049)

This commit improves the preexisting `component_api` fuzz target to use
arbitrary `Config` data. This, for example, helps exercise Pulle

Improve `Config`-related coverage of `component_api` (#12049)

This commit improves the preexisting `component_api` fuzz target to use
arbitrary `Config` data. This, for example, helps exercise Pulley in
addition to native. In general this also helps stress and ensure that no
config knobs are accidentally breaking ABI assumptions.

show more ...

Add async to the component_api fuzzer (#12047)

This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer wo

Add async to the component_api fuzzer (#12047)

This commit extends the preexisting `component_api` fuzzer in Wasmtime
to support `async`. This required a fair bit of refactoring to how the
fuzzer worked but the basic idea remains the same. This fuzzer
generates:

* An arbitrary component-model type signature (minus
resources/futures/streams)
* A component which imports a function of this signature from the host
and exports a function of this signature to the host.
* Internally the export is implemented with a component `caller` that
imports/exports this function signature.
* The `caller` component is instantiated with a `callee` component that
imports/exports this function signature.
* The `callee` component is instantiated with the host.

In essence a component model value is threaded into a component, to
another composed component, then back out to the host. The return value
then makes its way back through the same channel. The fuzz test ensures
that the parameters received in the host import are the same as those
passed to the export. Additionally the return value of the export is
ensured to be the same as the one that the host import returned. In
essence this is testing ABI handling in Wasmtime to ensure that
composition works correctly in addition to lifting/lowering code.

This fuzzer additionally has a "static" and "dynamic" mode where, at
compile time, N components are generated with different signatures and
use the "typed" APIs of Wasmtime. For "dynamic" `Val` is used to test
and arbitrary components are generated at fuzz-time. The fuzzer finally
executes this roundtrip in a loop multiple times in one fuzz test case
to test different runtime-shapes of values in addition to
compile-time-shapes of values.

The main addition in this commit is to extend all of this with the async
ABI. The following knobs were added and implemented:

* The function type used for the root component export, the function
between the composed components, and the function imported from the
host all have the ability to be an `async` function type now.

* The lifts/lowers, in all locations, can be configured with the various
ABIs supported (e.g. sync, async-callback, or async-stackful for
lifts, and sync/async for lowers).

* Like before the string encoding can be varied between the components
as well.

This is intended to stress combining different flavors of ABI with
different behaviors to ensure that all the various paths throughout
Wasmtime and such are hit. The goal of this fuzzer is to stress ABI
lifting/lowering, so this is not handling much related to async event
scheduling (that's for a future fuzzer).

In a follow-up commit I hope to extend this fuzzer with some async event
scheduling nonetheless. For example the fuzzer will generate an async
yield point before/after calling `task.return` or before/after calling
the host import. That is intended to stress `first_poll`-vs-not behavior
as it relates to ABI handling. None of that is yet implemented and for
this fuzzer async calls are assumed to always succeed immediately for now.

show more ...

Cleanup/add some testing in `wasmtime-fuzzing` (#12038)

Share the fuzz-generator-helpers across more tests and add smoke tests
for the dynamic/static component API tests too.

Split modules (#11993)

* Split GC to different modules and rename table_ops to gc_ops

* Remove table_ops from fuzz_targets. Renamed to gc_ops

* Address formatting failures

Add generic/typed `take_struct` imports + ops (#11713)

* add generic/typed take_struct imports + ops

* Address clippy error

* Address comments. Split GC related codes to its own modules. Update Ta

Add generic/typed `take_struct` imports + ops (#11713)

* add generic/typed take_struct imports + ops

* Address clippy error

* Address comments. Split GC related codes to its own modules. Update TableOps to GcOps as well as other related methods or DSs

* Remove table ops

* Revert "Remove table ops"

This reverts commit 0634e51bfa88c0c1c73c28b5b4704c1a5e923c04.

* Revert "Address comments. Split GC related codes to its own modules. Update TableOps to GcOps as well as other related methods or DSs"

This reverts commit e1d2bd05eadad26366293919a3b70fad9f0628c3.

* Address feedback and immediate generator crashes

---------

Co-authored-by: khan22 <[email protected]>

show more ...

Add `--async[=true|false]` flag to `wast` CLI (#11953)

This was needed to reproduce a fuzz bug recently and seemed like a good
piece of functionality to have.

Add first-class type access of `component::Func` (#11943)

When `Func:::{params,results}` was added we didn't have
`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it's
cheaper and

Add first-class type access of `component::Func` (#11943)

When `Func:::{params,results}` was added we didn't have
`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it's
cheaper and easier to access and work with that instead of the one-off
accessors on `Func`.

show more ...

Supply type information in `func_new` for components (#11944)

Originally the `Linker::func_new` type for components was modeled after
core wasm where a type was provided when the type was defined. T

Supply type information in `func_new` for components (#11944)

Originally the `Linker::func_new` type for components was modeled after
core wasm where a type was provided when the type was defined. This was
difficult, however, because there's no way to construct types right now
and instead a component had to be created and compiled to acquire type
information from it. Later various refactorings meant that it was
possible to drop the type information entirely from `func_new` meaning
that it was "typeless" in a sense, and the functionality relied on the
tagged nature of `Val` which always knows its type.

This has proven a bit difficult to integrate into Python in some work
I've been doing. Namely in Python component values are (at least IMO)
best represented as native Python values where possible. Native Python
doesn't distinguish, however, between integer bit widths (or
signededness). This means that converting a Python value to a component
value requires type information to guide the conversion process.
Currently when defining a function in a linker there's no way to get at
this type information meaning that the types would need to be supplied
in Python, bringing up the same shortcomings of not being able to create
types.

In lieu of filling out type constructors, which is itself quite
nontrivial, I've opted to do the next-most-easiest thing which is to
supply the type to the callee when an import is invoked. This means that
the callee has all the type information necessary. While this is
somewhat costly in that it clones a few arcs it's expected to be a drop
in the bucket compared to the inefficiencies of `Val` so it's at least
in the same spirit of the cost of the API right now.

My intention is to use this to update the C API for components and
eventually end up with type information when Python is invoked in
wasmtime-py. Also while I'm using wasmtime-py as a motivating case here
that's sort of just one example of a host embedding which doesn't have
the full fidelity of Rust's type system and might benefit from this.

show more ...

Put each component in its own store in wast testing (#11686)

This commit refactors the `wasmtime-wast` crate to place each component
in its own store. This is in contrast to core wasm testing where

Put each component in its own store in wast testing (#11686)

This commit refactors the `wasmtime-wast` crate to place each component
in its own store. This is in contrast to core wasm testing where all
instances get placed in the same store. The reason for this is that
components, in particular async state, is only fully defined so long as
a trap doesn't happen and once a trap happens it's expected the entire
store is torn down. This removes the need for the store to keep track of
exactly which instance all async tasks are associated with to ensure
that once any of them trap only the precise set of tasks necessary are
torn down. Instead Wasmtime can rely on embedders throwing away
`Store<T>` entirely.

The refactoring here provides a hook in `WastContext` to configure the
store but otherwise a new store is manufactured for all component
instances. Core wasm is unaffected. Tests are also unaffected as
same-store behavior isn't actually required by any tests.

show more ...

Fuzzing: ignore thrown exceptions during instantiation. (#11554)

This updates the instantiation logic to ignore inputs that throw an
exception during instantiation, just as it does for other kinds o

Fuzzing: ignore thrown exceptions during instantiation. (#11554)

This updates the instantiation logic to ignore inputs that throw an
exception during instantiation, just as it does for other kinds of
errors such as traps currently.

Fixes #11551.

show more ...

Exceptions: add basic support for fuzzing. (#11511)

* Enable use of exceptions in our fuzz module generator.

This patch was provided by Alex in #11505; it is thus

Co-authored-by: Alex Crichton <al

Exceptions: add basic support for fuzzing. (#11511)

* Enable use of exceptions in our fuzz module generator.

This patch was provided by Alex in #11505; it is thus

Co-authored-by: Alex Crichton <[email protected]>

* Add ExnRef comparison to differential result checking.

---------

Co-authored-by: Alex Crichton <[email protected]>

show more ...

Fix Out-of-memory in table-ops (#11392)

* Fix Out-of-memory in table-ops

* Remove missed println!

---------

Co-authored-by: Khagan Karimov <[email protected]>

Change `wasmtime wast` to be powered from JSON AST (#11113)

* Change `wasmtime wast` to be powered from JSON AST

This commit is a refactoring of the `wasmtime-wast` crate to use the
`json-from-wast

Change `wasmtime wast` to be powered from JSON AST (#11113)

* Change `wasmtime wast` to be powered from JSON AST

This commit is a refactoring of the `wasmtime-wast` crate to use the
`json-from-wast` crate added in bytecodealliance/wasm-tools#2247 instead
of the `wast` crate directly. The primary motivation for this PR is to
make spec tests more suitable for running inside of Miri. There are two
primary factors in how Miri is slow with wast tests today:

* Compiling WebAssembly modules. These are all embedded throughout
`*.wast` files and basically need to be precompiled to run in Miri.

* Parsing the `*.wast` script itself. The scripts are generally quite
large in the upstream spec test suite and parsing the script requires
parsing all modules as well, so this can take quite some time.

The goal of this commit was to leverage `json-from-wast` to perform much
of the heavy lifting on the host and then have a "cheap" parse step in
Miri which deserializes the JSON and runs precompiled `*.cwasm` files.
The main change then required of `wasmtime-wast` was to use the JSON AST
as its "IR" instead of `wast` directly. The actual transformation of the
`wasmtime-wast` crate isn't too bad, mostly just some refactorings here
and there.

A new `./ci/miri-wast.sh` script is added which first runs on native
with `wasmtime wast --precompile-save` and then runs in Miri with
`wasmtime wast --precompile-load`. In this manner I was able to get a
number of spec test `*.wast` files running in Miri.

Unfortunately, though, Miri is still far too slow to run in CI. One
major bottleneck is that the `*.json` files are pretty large and take a
nontrivial amount of time to parse. Another issue is that these tests
run a fair bit of code which with Miri's ~million-x slowdown. For the
first problem I tried using other more-binary serialization formats but
the JSON AST is unfortunately not compatible with many of them (e.g.
`postcard`, which we use for Wasmtime, is not compatible with the JSON
AST's structure in Rust types). For the latter I'm not sure what to
do...

In the end I figured this might be a reasonable refactoring to go ahead
and land anyway. It at least enables running `*.wast` tests in Miri
while removing a large part of the runtime slowdown. We can in theory
still allow-list some tests to run as they don't all take forever. Some
future breakthrough is still going to be required though to run
everything through Miri.

* Document usage

* Adjust lint

* Fix CI issues

show more ...

Update the `log` dependency (#11197)

* Update the `log` dependency

This enables getting warnings about formatting strings in the `log`
crate directives which are then additionally fixed here as wel

Update the `log` dependency (#11197)

* Update the `log` dependency

This enables getting warnings about formatting strings in the `log`
crate directives which are then additionally fixed here as well.

* Update dependency directive in `Cargo.toml`

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

Use `Waker::noop` from Rust 1.85 (#10804)

Now possible after #10785