Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

* Fix some minor `bindgen!` issues with `anyhow: true`

Found when updating Spin to Wasmtime 42.0.0 where some cases weren't
handled:

*

Fix some minor `bindgen!` issues with `anyhow: true` (#12657)

* Fix some minor `bindgen!` issues with `anyhow: true`

Found when updating Spin to Wasmtime 42.0.0 where some cases weren't
handled:

* Trappable functions with no result.
* Resource destructors.
* Functions with custom trappable errors.

* Shuffle some features

show more ...

Remove doc of cargo `signals-based-traps` feature (#12643)

This was removed awhile back, so remove the misleading documentation.

Closes #12634

Add support for fine-grained operator costs (#11572) (#12541)

Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring
per-operator fuel costs via `Config::operator_cost`. Previously

Add support for fine-grained operator costs (#11572) (#12541)

Introduce `OperatorCostStrategy` and `OperatorCost` to allow configuring
per-operator fuel costs via `Config::operator_cost`. Previously, operator
costs were hardcoded inline in both Cranelift and Winch code generation.
Now the cost logic is centralized in `wasmtime-environ` and referenced
from both backends via `tunables.operator_cost.cost(op)`.

`OperatorCostStrategy` is an enum with two variants:
- `Default`: reproduces the original hardcoded behavior (nop/drop/control
flow cost 0, everything else costs 1).
- `Table(Box<OperatorCost>)`: a per-operator cost table generated via
`wasmparser::for_each_operator!`.

Because `OperatorCostStrategy::Table` contains a `Box`, the type has a
destructor. This makes `Tunables` non-trivially droppable, which prevents
using the `..Tunables::default_miri()` functional update syntax in const
functions (E0493). To work around this, `default_miri`, `default_u32`,
and `default_u64` are changed to non-const fns. None of
these are called in const contexts, except in tests.

show more ...

Use `wasmtime_environ::collections::HashSet` in the `TypeRegistry` (#12522)

* Use `wasmtime_environ::collections::HashSet` in the `TypeRegistry`

* silence warning in certain build cfgs

Adjust Wasmtime's prelude/hash collections (#12509)

This commit updates Wasmtime's internal usage of hash maps and hash sets
to use the standard library when the `std` feature is enabled, as
opposed

Adjust Wasmtime's prelude/hash collections (#12509)

This commit updates Wasmtime's internal usage of hash maps and hash sets
to use the standard library when the `std` feature is enabled, as
opposed to using `hashbrown`. When `std` is disabled `hashbrown` is
still used, however. Additionally the prelude of `wasmtime` is now a
simple reexport of `wasmtime_environ`.

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

Fix generated code for `anyhow: true` in wit-bindgen (#12334)

* Fix generated code for `anyhow: true` in wit-bindgen

The trait was still declared as using `wasmtime::Result`. It now uses
`wasmtime:

Fix generated code for `anyhow: true` in wit-bindgen (#12334)

* Fix generated code for `anyhow: true` in wit-bindgen

The trait was still declared as using `wasmtime::Result`. It now uses
`wasmtime::anyhow::Result` and we re-export `anyhow` through `wasmtime::anyhow`
-- with `doc(hidden)` since it is only for macro-generated code -- when the
`anyhow` cargo feature is enabled.

* Fix macro expansion test expectations

show more ...

Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)

* Polyfill `ToWasmtimeResult` and add eventually-necessary call sites

This commit polyfills `wasmtime_internal_error::To

Polyfill `ToWasmtimeResult` and add eventually-necessary call sites (#12308)

* Polyfill `ToWasmtimeResult` and add eventually-necessary call sites

This commit polyfills `wasmtime_internal_error::ToWasmtimeResult` in
`wasmtime_environ`, adds the cargo feature plumbing that will eventually connect
to the `"wasmtime_internal_error/anyhow"` cargo feature but for now just
configures this polyfill, and adds uses of the polyfill at all the sites that
will be necessary once we swap out `anyhow` for
`wasmtime_internal_error`. Currently, the polyfill is just an identity function,
because `wasmtime::Result`/`wasmtime_environ::error::Result` is just another
name for `anyhow::Result`. Once we do move away from `anyhow`, however, that
will no longer be the case, and these uses will do the necessary conversion.

My goal with landing this as an incremental commit is to make it so that the
actual commit that does the error crate swap out can be as close to _just_ the
`Cargo.toml` dependency change, without any other code changes as much as
possible. This, in turn, means that swap out should be super easy to revert, if
necessary.

* Add a couple more `.to_wasmtime_result()` invocations in fuzz code

* Revert "Add a couple more `.to_wasmtime_result()` invocations in fuzz code"

This reverts commit b33696e5f63f7eed731ca9dad10fec5e55a550d3.

* Move cranelift fuzz targets back to anyhow

* Fix cargo feature enablement for explorer

show more ...

Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)

We are trying to move to `format_err!` instead.

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtim

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`

Instead of `anyhow::Error`.

This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`
module, updates the prelude to include these new error-handling types, redirects
our top-level `wasmtime::{Error, Result}` re-exports to re-export
`wasmtime::error::{Error, Result}`, and updates various use sites that were
directly using `anyhow` to use the new `wasmtime` versions.

This process also required updating the component macro and wit-bindgen macro to
use the new error types instead of `anyhow`.

Part of https://github.com/bytecodealliance/wasmtime/issues/12069

* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense

* cargo fmt

* Move `crate::error::Thing` to `crate::Thing` where it makes sense

show more ...

Update nightly rust used in CI (#11856)

* Update nightly rust used in CI

A few more warnings are cropping up so squash them.

* Frob the `unreachable_code` lint

Looks like nightly rust has gotten

Update nightly rust used in CI (#11856)

* Update nightly rust used in CI

A few more warnings are cropping up so squash them.

* Frob the `unreachable_code` lint

Looks like nightly rust has gotten much more aggressive about linting on
unreachable code.

prtest:full

* Allow some more warnings...

show more ...

Update nightly Rust used in CI (#11755)

* Update nightly Rust used in CI

Keeping it up-to-date

prtest:full

* Fix unused warnings on nightly

* Rename rustdoc feature

* Adjust some removals

Resolve `unsafe_op_in_unsafe_fn` in `wasmtime` crate (#11432)

Just a few unsafe blocks remain

Closes #11180

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

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

Enable `allow_attributes_without_reason` (#11195)

* Enable `allow_attributes_without_reason`

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

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

prtest:full

* Adjust some directives

* Fix some warnings

* Fix stack switching size tests on unix

* Don't have a conditional `Drop` impl

* Force `testing_freelist` method to be used

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

show more ...

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

* fix(no_std)!: respect `std` feature when target is windows/unix

BREAKING CHANGE: the fix disables standard features for de

fix(no_std)!: respect `std` feature when target is windows/unix (#11152)

* fix(no_std)!: respect `std` feature when target is windows/unix

BREAKING CHANGE: the fix disables standard features for dependents that use wasmtime with `default-features = false`.

* fix cargo check workflow

* Don't require `std` feature for invalid faults

Fill out the `compile_error!` to avoid failing a build.

* addressing review comments

* add `std` to `stack-switching` feature

* remove `rustix/mm` from `std` feature dependencies

* add `std` feature flag to `jit-icache-coherence`
- The `std` feature gates the use of standard library for icache coherence in Windows; otherwise, defaults to the `libc` implementation.
- The `std` feature of Wasmtime now depends on the `wasmtime-jit-icache-coherence/std`

* Only include jit-icache-coherence on `std` builds

prtest:full

* Fix some idiom issues

* More idiom issues

* Require `std` for loading native code

---------

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

show more ...

Update cache configuration documentation and references (#10859)

Remove references to deprecated cache config methods and update to use the new simplified `Config::cache` API. Also remove the mandat

Update cache configuration documentation and references (#10859)

Remove references to deprecated cache config methods and update to use the new simplified `Config::cache` API. Also remove the mandatory `enabled` field from cache configuration documentation since all cache settings are now optional.

show more ...

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtim

Update Wasmtime to the 2024 Rust Edition (#10806)

* Update Wasmtime to the 2024 Rust Edition

Now that our MSRV supports the 2024 edition it's possible to make this
switch. This commit moves Wasmtime to the 2024 Edition to keep
up-to-date with Rust idioms and access many of the edition features
exclusive to the 2024 edition.

prtest:full

* Reformat with the 2024 edition

show more ...

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

* Enable the `unsafe-op-in-unsafe-fn` lint

This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the
entire workspace. This lint will

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)

* Enable the `unsafe-op-in-unsafe-fn` lint

This commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for the
entire workspace. This lint will be warn-by-default in the 2024 edition
so this is intended to smooth the future migration to the new edition.

Many `unsafe` blocks were added in places the lint warned about, with
two major exceptions. The `wasmtime` and `wasmtime-c-api` crates simply
expect this lint to fire and effectively disable the lint. They're too
big at this time to do through this PR. My hope is that one day in the
future they'll be migrated, but more realistically that probably won't
happen so these crates just won't benefit from this lint.

* Fix nostd fiber build

prtest:full

* Fix build on Windows

* Fix asan build

show more ...

Enable warnings if `cranelift` is disabled (#10157)

Continuation of work in #10131.

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combi

Enable warnings if `gc` is disabled (#10149)

* Enable warnings if `gc` is disabled

Continuation of work in #10131. This additionally handles turning off
`gc-null` and `gc-drc` and the various combinations within.

* Fix some more warnings

* Fix a feature combo build

show more ...

Enable warnings if `async` is disabled (#10145)

* Enable warnings if `async` is disabled

Continuation of work in #10131.

This required a number of organizational changes to help cut down on
`#[cfg

Enable warnings if `async` is disabled (#10145)

* Enable warnings if `async` is disabled

Continuation of work in #10131.

This required a number of organizational changes to help cut down on
`#[cfg]`, notably lots of async-related pieces from `store.rs` have
moved to `store/async_.rs` to avoid having lots of conditional imports.
Additionally this removes all of the `#[cfg]` annotations on those
methods already.

Additionally the signature of `AsyncCx::block_on` was updated to be a
bit more general to ideally remove the need for `Pin` but it ended up
not panning out quite just yet. In the future it should be possible to
remove the need for `Pin` at callsites though.

* Rebase conflicts

show more ...

Enable warnings if `pooling-allocator` is disabled (#10142)

* Enable warnings if `pooling-allocator` is disabled

Continuation of work in #10131

* Fix windows build

Enable warnings if `component-model` is disabled (#10141)

Continuation of work in #10131

Enable warnings if `cache` is disabled (#10140)

Continuation of work in #10131

Enable warnings if `threads` is disabled (#10136)

Continuation of work in #10131