Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our fl

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our flags to pass
`-Dwarnings` to ensure that we have warning-free doc builds when all
features are enabled at least.

There were quite a lot of preexisting issues to fix, so this
additionally goes through and fixes all the warnings that cropped up.

* Update nightly toolchain again

prtest:full

* Update another nightly

* Fix a warning in generated code

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 `wasmtime-wasi` to `wasmtime::error` (#12294)

* Migrate wiggle and wiggle generate to `wasmtime::error`

* Fix testing `wiggle` and `wiggle-test` in isolation

When doing plain old `cargo te

Migrate `wasmtime-wasi` to `wasmtime::error` (#12294)

* Migrate wiggle and wiggle generate to `wasmtime::error`

* Fix testing `wiggle` and `wiggle-test` in isolation

When doing plain old `cargo test -p wiggle` (or `wiggle-test`) the test would
fail due to linking errors because Wasmtime's `std` cargo feature (and maybe
others) wasn't being enabled. The crate's tests would pass when run as part of
the whole workspace, however, because of cargo feature resolution and other
crates that enabled the necessary features, which is why CI is green.

* Remove direct anyhow dependency in wiggle-test

* Migrate wasi-nn to `wasmtime::error`

* Migrate wasi-keyvalue to `wasmtime::error`

* Migrate wasi-io to `wasmtime::error`

* Migrate wasi-http to `wasmtime::error`

* Migrate wasi-config to `wasmtime::error`

* Migrate wasi-common to `wastime::error`

This is another interesting one because wasi-common is used internally to
Wasmtime but also by other projects. Therefore, rather than using
`wastime::error::*` and making `wasmtime` a hard dependency, we use just
`wasmtime_environ::error`.

* cargo fmt

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

show more ...

Expand some docs on wasmtime-wasi (#11598)

Add public docs for APIs added in #11593 and additionally internalize
some crate fields to avoid exposing too many internal implementation
details.

Make some WASI types public (#11593)

If these are private it's impossible to implement a version of `add_to_linker()` that only pulls in some of this WASI implementation (e.g if you want to provide

Make some WASI types public (#11593)

If these are private it's impossible to implement a version of `add_to_linker()` that only pulls in some of this WASI implementation (e.g if you want to provide a custom implementation of some parts of it).

show more ...

Mirror WASIp{2,3} cli implementations (#11378)

* Mirror WASIp{2,3} cli implementations

This is an implementation of #11362 but for the `wasi:cli`
implementation of WASIp2.

* Fix unused field witho

Mirror WASIp{2,3} cli implementations (#11378)

* Mirror WASIp{2,3} cli implementations

This is an implementation of #11362 but for the `wasi:cli`
implementation of WASIp2.

* Fix unused field without p3

show more ...

Share stdio implementations in WASIp{2,3} (#11368)

* Share stdio implementations in WASIp{2,3}

This commit is a refactoring of the
`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more co

Share stdio implementations in WASIp{2,3} (#11368)

* Share stdio implementations in WASIp{2,3}

This commit is a refactoring of the
`wasmtime_wasi::{cli,p2::stdio,p3::cli}` modules to share more code. The
generic trait object that represents stdio now has the ability to
acquire either a p2 stream or an async-based stream. The acquisition of
p2 has a default implementation so in the future this can be primarily
`Async{Read,Write}`-based.

Many trait implementations and types and such were all consolidated
together into the `wasmtime_wasi::cli` module. One-off implementations
in p2/p3 are now shared in one location and `WasiCtxBuilder` no longer
needs any generics for different stdio streams.

Functionally this necessitated the addition of `Async{Read,Write}`
implementations for some "base" implementations of stdio primitives.
Implementations were mostly trivial except for a few adapters which were
significantly more complicated, namely the `Async{Read,Write}Stream`
adapter which converts a single `Async{Read,Write}` into the stdio of a
component.

Finally the stdin implementation for p3 was refactored to avoid use of
`tokio::io::stdin()` which generally isn't safe to use. It's replaced
with a custom `AsyncRead` using the worker thread implementation we have
in the crate already.

Eventually I hope to remove the distinction between `p{2,3}::WasiCtx`
and have these be the same type. This will make it nicer to only have a
single `WasiView` trait and additionally make it easier to
simultaneously implement all of WASIp{1,2,3}.

* Fix build of C API

* Fix build of `wasmtime serve`

show more ...

feat(wasip3): implement `wasi:cli` (#11257)

* feat(wasi): introduce common CLI context

Signed-off-by: Roman Volosatovs <[email protected]>

* chore(wasi): implement traits for boxed values

Si

feat(wasip3): implement `wasi:cli` (#11257)

* feat(wasi): introduce common CLI context

Signed-off-by: Roman Volosatovs <[email protected]>

* chore(wasi): implement traits for boxed values

Signed-off-by: Roman Volosatovs <[email protected]>

* chore(wasi): implement `Default` for common WASI builder

Signed-off-by: Roman Volosatovs <[email protected]>

* feat(wasip3): implement `wasi:cli`

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor: require streams to be `Send`

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor: avoid typing `WasiCli` in task

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor: remove `Unpin` bound from stream I/O

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor: remove `ResourceView`

Signed-off-by: Roman Volosatovs <[email protected]>

* chore: update `serve` to new WASI `isatty` API

Signed-off-by: Roman Volosatovs <[email protected]>

* chore: adapt to stream API changes

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor: avoid `**` syntax

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor(wasip3): remove `Impl` wrappers

Signed-off-by: Roman Volosatovs <[email protected]>

* refactor(wasip3): use shorthand closure syntax

Signed-off-by: Roman Volosatovs <[email protected]>

* chore: account for different env on different targets

prtest:full

Signed-off-by: Roman Volosatovs <[email protected]>

---------

Signed-off-by: Roman Volosatovs <[email protected]>

show more ...