Fix a copy/paste typo in `StreamAny` (#12871)

When closing, close a stream, not a future. Fixes the test added here as
well.

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are c

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are confident enough in the fuzzing of
component-model-async such that we could confidently say we're
exercising the vast majority of possible panics. Development of
component-model-async has shown a steady trickle of panics over the
course of the development of the feature, and this trend has been
persistent over time as well.

An attempt was made in #12119 to add a fuzzer dedicated to async events
but that didn't actually find anything in development and it has missed
a number of panics present before and discovered after its introduction.
Overall I do not know how to improve the fuzzer to the point that it
would find pretty much all of the existing async-related panics over
time.

To help address this concern of the `concurrent.rs` implementation this
commit goes through and replaces things like `unwrap()`, `assert!`,
`panic!`, and `unreachable!` with an error-producing form. The benefit
of this is that a bug in the implementation is less likely to result in
a panic and instead just results in a non-spec-compliant trap. The
downside of doing this though is that it can become unclear what errors
are "first class traps", or expected to be guest reachable, and which
are expected to be bugs in Wasmtime. To help address this I've performed
a few refactorings here as well.

* Some traps previously present as error strings are now promoted to
using `Trap::Foo` instead. This has some refactoring of the Rust/C
side as well to make it easier to define new variants. Tests were
additionally added for any trap messages that weren't previously
tested as being reachable.

* A new `bail_bug!` macro was added (internally) for Wasmtime. This is
coupled with a concrete `WasmtimeBug` error type (exported as
`wasmtime::WasmtimeBug`). The intention is that `bail!` continues to
be "here's a string and I'm a bit too lazy to make a concrete error"
while `bail_bug!` indicates "this is a bug in wasmtime please report
this if you see it".

The rough vision is that if an error condition is reached, and the system
is not broken in such a way that panicking is required, then `bail_bug!`
can be used to indicate a bug in Wasmtime as opposed to panicking. This
reduces the real-world impact of hitting these scenarios by downgrading a
CVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not all
panics are able to be transitioned to this as some are load bearing from
a safety perspective or similar (or indicate something equally broken),
but the vast majority of cases are suitable for "return a trap, lock
down the store, and let destructors take care of everything else".

This change additionally has resulted in API changes for `FutureReader`
and `StreamReader`. For example creation of these types now returns a
`Result` for when the `ResourceTable` is full, for example, instead of
panicking.

* Fix CI build

* Translate `WasmtimeBug` to panics in debug mode

* Review comments

* Refactor some stream methods for fewer panics

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

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

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

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

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

* Remove new usage of anyhow that snuck in

cm-async: Start to fill out `{Future,Stream}Any` (#12142)

* cm-async: Start to fill out `{Future,Stream}Any`

This commit is the first step down the road of filling out the
preexisting, but empty/bu

cm-async: Start to fill out `{Future,Stream}Any` (#12142)

* cm-async: Start to fill out `{Future,Stream}Any`

This commit is the first step down the road of filling out the
preexisting, but empty/buggy, `FutureAny` and `StreamAny` types. These
are intended to behave similarly to `ResourceAny` where the embedder
doesn't have static knowledge ahead of time about the type of the
future/stream in use. Changes made here are:

* `ComponentType for {Stream,Future}Reader<T>` now correctly typecheck
the `T`.
* Conversion to/from `*Any` types now properly typechecks the payload
type against the expected type.
* `{Future,Stream}Any` now live in their own file with the matrix of
conversions to the typed variants.
* A `close` method was added to `*Any` types.

These types are not currently directly constructible but this will
likely be relaxed in the future. Additionally the host can't actually
use these values without knowing the type, which is another restriction
that will be relaxed in the future (aka implemented).

cc #11161

* Fix tests

* Skip a test on miri

show more ...