Merge `wasmtime-math` into `wasmtime-core` (#12398)

* Merge `wasmtime-math` into `wasmtime-core`

No real need to have two "core" crates, let's just have one.

* Fix warnings

Migrate winch-codegen to `wasmtime_environ::error` (#12297)

Stack switching: Infrastructure and runtime support (#10388)

* [pr1] base

* prtest:full

* make sure to use ControlFlow result in trace_suspended_continuation

* stack-switching: cleanup: remove st

Stack switching: Infrastructure and runtime support (#10388)

* [pr1] base

* prtest:full

* make sure to use ControlFlow result in trace_suspended_continuation

* stack-switching: cleanup: remove stray c-api changes

These are remnants of unrelated wasmfx wasmtime experiments, possibly
suitable for later submission against upstream.

* stack-switching: reuse async_stack_size

* stack-switching: delete delete_me debugging

* stack-switching: address feedback in environ::types

* stack-switching: remove unused code from vmoffsets

* stack-switching: drop dependency on std

* stack-switching: add compilation checks to ci matrix

* stack-switching: remove debug_println cruft

* stack-switching: export environ consts consistently

* stack-switching: export vm pub items consistently

* table_pool: reduced capacity for large elements

VMContRef elements which takes up two words and we don't want to
double the size of all tables in order to support storing these.
This change changes the table to target storing the requested
max number of elements if they are "nominally" sized with
(potentially) reduced capacity for non-nominally sized types when
encountered.

Continuations are the only type of element which may result in
fewer table slots being available than requested.

* stack-switching: extend conditional compilation

A fair bit of the definitions for stack switching are still
enabled, but this patch takes things a bit further to avoid
compilation problems; notably, cont_new is now not compiled
in unless the feature is enabled.

* stack-switching: formatting fixes

* stack-switching: address new clippy checks

In addition, to get clippy to fully pass, plumbed in
additional config to make winch paths happy; there's no
impl for winch yet but plumbing through the feature is
required to make paths incorporating macros at various
layers satisfied (and it is expected we'll use the
features in the future).

* stack-switching: more conditional compilation fixes

* stack-switching: additional conditional compile on table builtins for continuations

* stack-switching: additional conditional compile fixes

* stack-switching: additional conditional compile in store

* stack-switching: remove overly strict assertion

* stack-switching: remove errantly dropped no_mangle in config c-api

* stack-switching: VMContObj::from_raw_parts

* stack-switching: remove duplicate async_stack_size feature check

* stack-switching: VMArray -> VMHostArray

* stack-switching: remove unnecessary clippy exception

* stack-switching: fix docs referenced VMRuntimeLimits

* stack-switching: fix doc typo

* stack-switching: follow recommendations for type casts

* stack-switching: use usize::next_multiple_of

* stack-switching: update outdated comment

* stack-switching: use feature gate instead of allow(dead_code)

* stack-switching: rework backtrace using chunks/zip

* stack-switching: move tests to footer module

This is a bit more consistent with the prevailing style
in tree and (subjectively) makes finding the tests
as a reader more straightforward.

Tests left unchanged sans some import cleanup.

* stack-swictchding: verify stack_chain offsets at runtime

* fixup! stack-switching: use feature gate instead of allow(dead_code)

* stack-switching: document continuation roots tracing using match arms

---------

Co-authored-by: Paul Osborne <[email protected]>

show more ...

Refactor float-to-int conversion bounds (#10884)

This commit deduplicates a number of locations throughout the codebase
that contain the bounds for float-to-int conversions. These bounds are
relativ

Refactor float-to-int conversion bounds (#10884)

This commit deduplicates a number of locations throughout the codebase
that contain the bounds for float-to-int conversions. These bounds are
relatively subtle and not easy to get right so it's probably best to
keep them all centralized in one location.

show more ...

x64: remove `Inst::AluRmiR` (#10687)

* Remove `AluRmiR`

This change completely removes the `Inst::AluRmiR` variant along with
associated code. The only remaining place this was used was via the
`In

x64: remove `Inst::AluRmiR` (#10687)

* Remove `AluRmiR`

This change completely removes the `Inst::AluRmiR` variant along with
associated code. The only remaining place this was used was via the
`Inst::alu_rmi_r` helper, which is replaced by `Inst::add|sub|and|or...`
helpers.

The lowering, implemented here in Rust, is meant to mimic the behavior
also-encoded in ISLE. In discussions about this in the Cranelift
meeting, this duplication was of low concern. Nevertheless, this could
be improved in the future. In any case, this commit clearly identifies
the locations that build an ALU instruction in Rust: ABI logic, Winch,
and long-ish lowering sequences.

* Make `Inst::<alu>` emit smaller immediate code

To avoid many offset changes in disassembly tests, this change improves
the `Inst::<alu>` helpers by teaching them how to emit smaller `mi`
encodings when the immediate part can fit in an 8-bit slot.

* Bless all affected Cranelift tests

* Fix up Cranelift emit tests

In the `Inst::<alu>` helpers, I chose to use the `rm` format of the ALU
instructions and not the previously-used `mr` format. Either format is
fine for reg-reg operations but but would be incorrect if any previous
uses of these helpers had inserted the `LOCK` prefix (`0xF0`)
immediately prior; the `LOCK` prefix is only valid on instructions with
a destination memory operand (i.e., `mr`, where `m` is read-write). I
did not find any uses like this and this would have been quite an unsafe
way to encode instructions anyways. I chose to use `rm` because it fits
the helper signature better: if we ever decided to use the memory
variant of the read operand (i.e., `src: RegMemImm`), then the `rm`
format is the right thing to use. But this change of format means that
we emit slightly different instructions for these long, atomic
sequences.

* Convert Winch to use assembler ALU instructions

Up until now, Winch had been using the `Inst::alu_rmi_r` for generating
the instructions it needed to emit. With this helper now gone, we have a
chose: (a) continue using `Inst` helpers that use the new assembler or
(b) use the new assembler directly. This change adopts option (b).

Because of how `cranelift-codegen`'s register allocation works, we have
been passing a `PairedGpr` into the read-write slots of the new
assembler (this enables us to separate out the read-side and write-side
as separate virtual registers). For Winch to use this, we have to expose
`PairedGpr` via the now-public `isa::x64::inst::external` module.

* Use `cranelift-assembler-x64` unconditionally in Winch

Due to how Cargo optional dependencies work and how we have chosen to
implement backend Cargo features, we decided in the Cranelift meeting to
just include this dependency unconditionally.

* Bless all affected Wasmtime tests

* review: refactor to remove the need for `Inst::<alu>` helpers entirely

* review: add `Inst::{add|sub}q_mi` helpers

This reduces the number of places we need to check for the opportunity
for smaller encodings.

* review: accept `impl Into<...>` in assembly constructors

This further reduces the boilerplate involved in creating new
instructions.

show more ...

winch: Gracefully handle compilation errors (#9851)

* winch: Gracefully handle compilation errors

Closes: https://github.com/bytecodealliance/wasmtime/issues/8096

This commit threads `anyhow::Resu

winch: Gracefully handle compilation errors (#9851)

* winch: Gracefully handle compilation errors

Closes: https://github.com/bytecodealliance/wasmtime/issues/8096

This commit threads `anyhow::Result` through most of Winch's
compilation process in order to gracefully handle compilation errors
gracefully instead of panicking.

The error classification is intentionally very granular, to avoid string
allocation which could impact compilation performance.

The errors are largely fit in two categories:

* Unimplemented/Unsupported
* Internal

The firs category signals partial or no support for Wasmtime features
and or Wasm proposals. These errors are meant to be temporary while
such features or proposals are in development.

The second category signals that a compilation invariant was not met.
These errors are considered internal and their presence usually means
a bug in the compiler.

* Include `Result` in the MacroAssembler

This commit updates the MacroAssembler trait to require returning
`Result<T>` on every method in the interface, making it easier to
detect partial support for Masm instructions.

show more ...

Update MSRV to 1.81.0 (#9692)

* Update MSRV to 1.81.0

Coupled with today's release of Rust 1.83 this bumps our MSRV on
Wasmtime to 1.81. This also updates the nightly used for testing too.

prtest:

Update MSRV to 1.81.0 (#9692)

* Update MSRV to 1.81.0

Coupled with today's release of Rust 1.83 this bumps our MSRV on
Wasmtime to 1.81. This also updates the nightly used for testing too.

prtest:full

* Propagate some necessary features through Winch

* Remove std feature from adapter configuration

Looks to be historical at this point and is no longer needed

show more ...

Update pulley-interpreter and winch-codegen versions (#9371)

* Update pulley-interpreter and winch-codegen versions

Update these two crates to match the Wasmtime crate version instead of
having sep

Update pulley-interpreter and winch-codegen versions (#9371)

* Update pulley-interpreter and winch-codegen versions

Update these two crates to match the Wasmtime crate version instead of
having separate version tracks. Helps keep everything in-sync with
fewer versions to worry about in general.

* Update cargo-vet

show more ...

Bump Wasmtime to 26.0.0 (#9200)

Co-authored-by: Wasmtime Publish <[email protected]>

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
s

Add `rust-version.workspace = true` to all crates (#9112)

Right now this is only on some crates such as `wasmtime` itself and
`wasmtime-cli`, but by applying it to all crates it helps with version
selection of those using just Cranelift for example.

show more ...

Bump Wasmtime to 25.0.0 (#9077)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 24.0.0 (#8902)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 23.0.0 (#8743)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 22.0.0 (#8553)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 21.0.0 (#8302)

Co-authored-by: Wasmtime Publish <[email protected]>

Exit through Cranelift-generated trampolines for builtins (#8152)

* Exit through Cranelift-generated trampolines for builtins

This commit changes how builtin functions in Wasmtime (think
`memory.gr

Exit through Cranelift-generated trampolines for builtins (#8152)

* Exit through Cranelift-generated trampolines for builtins

This commit changes how builtin functions in Wasmtime (think
`memory.grow`) are implemented. These functions are required to exit
through some manner of trampoline to handle runtime requirements for
backtracing right now. Currently this is done via inline assembly for
each architecture (or external assembly for s390x). This is a bit
unfortunate as it's a lot of hand-coding and making sure everything is
right, and it's not easy to update as it's multiple platforms to update.

The change in this commit is to instead use Cranelift-generated
trampolines for this purpose instead. The path for invoking a builtin
function now looks like:

* Wasm code calls a statically known symbol for each builtin.
* The statically known symbol will perform exit trampoline duties (e.g.
pc/fp/etc) and then load a function pointer to the host
implementation.
* The host implementation is invoked and then proceeds as usual.

The main new piece for this PR is that all wasm modules and functions
are compiled in parallel but an output of this compilation phase is what
builtin functions are required. All builtin functions are then unioned
together into one set and then anything required is generated just
afterwards. That means that only one builtin-trampoline per-module is
generated per-builtin.

This work is inspired by #8135 and my own personal desire to have as
much about our ABI details flowing through Cranelift as we can. This in
theory makes it more flexible to deal with future improvements to our
ABI.

prtest:full

* Fix some build issues

* Update winch test expectations

* Update Winch to use new builtin shims.

This commit refactors the Winch compiler to use the new trampolines for
all Wasmtime builtins created in the previous commits. This required a
fair bit of refactoring to handle plumbing through a new kind of
relocation and function call.

Winch's `FuncEnv` now contains a `PrimaryMap` from `UserExternalNameRef`
to `UserExternalName`. This is because there's now more than one kind of
name than just wasm function relocations, so the raw index space of
`UserExternalNameRef` is no longer applicable. This required threading
`FuncEnv` to more locations along with some refactorings to ensure that
lifetimes work out ok.

The `CompiledFunction` no longer stores a trait object of how to map
name refs to names and now directly has a `Primarymap`. This also means
that Winch's return value from its `TargetIsa` is a `CompiledFunction`
as opposed to the previous just-a-`MachBuffer` so it can also package up
all the relocation information. This ends up having `winch-codegen`
depend on `wasmtime-cranelift-shared` as a new dependency.

* Review feedback

show more ...

Bump Wasmtime to 20.0.0 (#8046)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 19.0.0 (#7868)

Co-authored-by: Wasmtime Publish <[email protected]>

winch: Emit unwind info in the x64 backend (#7798)

* Enable all winch tests on windows

prtest:mingw-x64

* Plumb through x64 unwind info creation

* Add the frame regs unwind info

* Emit UnwindInf

winch: Emit unwind info in the x64 backend (#7798)

* Enable all winch tests on windows

prtest:mingw-x64

* Plumb through x64 unwind info creation

* Add the frame regs unwind info

* Emit UnwindInfo::SaveReg instructions

* Review feedback

* Comment the offset_downward_to_clobbers value

show more ...

Bump Wasmtime to 18.0.0 (#7751)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 17.0.0 (#7631)

Co-authored-by: Wasmtime Publish <[email protected]>

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at th

Configure workspace lints, enable running some Clippy lints on CI (#7561)

* Configure Rust lints at the workspace level

This commit adds necessary configuration knobs to have lints configured
at the workspace level in Wasmtime rather than the crate level. This
uses a feature of Cargo first released with 1.74.0 (last week) of the
`[workspace.lints]` table. This should help create a more consistent set
of lints applied across all crates in our workspace in addition to
possibly running select clippy lints on CI as well.

* Move `unused_extern_crates` to the workspace level

This commit configures a `deny` lint level for the
`unused_extern_crates` lint to the workspace level rather than the
previous configuration at the individual crate level.

* Move `trivial_numeric_casts` to workspace level

* Change workspace lint levels to `warn`

CI will ensure that these don't get checked into the codebase and
otherwise provide fewer speed bumps for in-process development.

* Move `unstable_features` lint to workspace level

* Move `unused_import_braces` lint to workspace level

* Start running Clippy on CI

This commit configures our CI to run `cargo clippy --workspace` for all
merged PRs. Historically this hasn't been all the feasible due to the
amount of configuration required to control the number of warnings on
CI, but with Cargo's new `[lint]` table it's possible to have a
one-liner to silence all lints from Clippy by default. This commit by
default sets the `all` lint in Clippy to `allow` to by-default disable
warnings from Clippy. The goal of this PR is to enable selective access
to Clippy lints for Wasmtime on CI.

* Selectively enable `clippy::cast_sign_loss`

This would have fixed #7558 so try to head off future issues with that
by warning against this situation in a few crates. This lint is still
quite noisy though for Cranelift for example so it's not worthwhile at
this time to enable it for the whole workspace.

* Fix CI error

prtest:full

show more ...

Bump Wasmtime to 16.0.0 (#7482)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 15.0.0 (#7154)

Co-authored-by: Wasmtime Publish <[email protected]>

Bump Wasmtime to 14.0.0 (#6964)

Co-authored-by: Wasmtime Publish <[email protected]>