Add "GC Zeal" infrastructure for additional, aggressive GC assertions (#12921)

* Add "GC Zeal" infrastructure for additional, aggressive GC assertions

This initial commit just sets up the initial G

Add "GC Zeal" infrastructure for additional, aggressive GC assertions (#12921)

* Add "GC Zeal" infrastructure for additional, aggressive GC assertions

This initial commit just sets up the initial GC Zeal infrastructure, it doesn't
actually start using it anywhere yet.

* Adds support for `cfg(gc_zeal)` to `crates/wasmtime/build.rs` and
`crates/cranelift/build.rs`
* Defines `gc_assert!` macro
* Defines `wasmtime_environ::gc::POISON` constant for GC heap poisoning
* Adds debug assert that `POISON` doesn't overlap any valid `VMGcKind`
discriminant
* Adds CI job to run GC-related tests with `cfg(gc_zeal)`

* Review feedback

show more ...

Fix logic and double-drop UB in `WriteBuffer` impls (#12870)

For component-model-async this fixes logic and undefined behavior issues
in the implementation of the `WriteBuffer` trait for various typ

Fix logic and double-drop UB in `WriteBuffer` impls (#12870)

For component-model-async this fixes logic and undefined behavior issues
in the implementation of the `WriteBuffer` trait for various types.
Notably all types didn't respect the `unsafe` contract of the
`WriteBuffer::take` method by limiting the number of results to what was
requested. This flawed detail, when coupled with other implementation
details, led to both incorrect results and UB in the case that
`VecBuffer<T>` was used where `T` had a `Drop` implementation. This is
not a security issue because component-model-async is not yet Tier 1 and
thus is exempt from the security issue process, but this is nonetheless
something needed to be fixed.

show more ...

feat(p3): implement wasi:tls (#12834)

* Split off p2-specific bits into submodule

* Vendor the 0.3.0-draft WIT files

* Host traits scaffolding

* Rename p2 test

* Work around bug in `tokio-native

feat(p3): implement wasi:tls (#12834)

* Split off p2-specific bits into submodule

* Vendor the 0.3.0-draft WIT files

* Host traits scaffolding

* Rename p2 test

* Work around bug in `tokio-native-tls`

* Create error type

* Implement p3

Co-authored-by: Roman Volosatovs <[email protected]>

* Fix test on Windows' SChannel

Same reason as described in https://github.com/bytecodealliance/wasmtime/pull/11064

* Satisfy clippy

* Fix typo

---------

Co-authored-by: Roman Volosatovs <[email protected]>

show more ...

Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, simi

Debugging: add integration test with LLDB and some minor tweaks. (#12856)

This PR adds:

- An integration-test that runs LLDB against the Wasmtime CLI to
verify basic debugging functionality, similar to the existing
native-debug tests.

- A CI job that runs the above in CI.

- Some minor tweaks to the gdbstub debugger design:
- Rather than the initial single-step to get to the first Wasm
instruction where module(s) will be instantiated into the store
and visible to the debugger, we pre-register modules with the
store eagerly. This avoids the slightly hacky flow and also is a
preparation step for `wasmtime serve` debugging, where we can't
single-step into execution eagerly (because execution doesn't
start at all until an HTTP request arrives).
- Add a separate message-printing path for "debugger info messages",
allowing us to print the "debugger is listening on <PORT>" message
without inheriting stderr for the whole debugger component
environment. This message is necessary for the above integration
test (it parses the message to determine when the debuggee is ready).

show more ...

CI: Add a check for cranelift-codegen (only x86 and aarch64) on no_std tagets (#12812)

* CI: Add a check for cranelift-codegen (only x86 and aarch64) on no_std tagets

* Change -F to --features

* F

CI: Add a check for cranelift-codegen (only x86 and aarch64) on no_std tagets (#12812)

* CI: Add a check for cranelift-codegen (only x86 and aarch64) on no_std tagets

* Change -F to --features

* Fix CI: remove unused imports when building without unwind

* Cargo fmt

show more ...

Debugging: add builtin gdbstub component. (#12771)

* Debugging: add builtin gdbstub component.

This adds a debug component that makes use of the debug-main world
defined in #12756 and serves the gd

Debugging: add builtin gdbstub component. (#12771)

* Debugging: add builtin gdbstub component.

This adds a debug component that makes use of the debug-main world
defined in #12756 and serves the gdbstub protocol, with Wasm
extensions, compatible with LLDB.

This component is built and included inside the Wasmtime binary, and
is loaded using the lower-level `-D debugger=...` debug-main option;
the user doesn't need to specify the `.wasm` adapter
component. Instead, the user simply runs `wasmtime run -g <PORT>
program.wasm ...` and Wasmtime will load and prepare to run
`program.wasm` as the debuggee, waiting for a gdbstub connection on
the given TCP port before continuing.

The workflow is:

```
$ wasmtime run -g 1234 program.wasm
[ wasmtime starts and waits for connection ]

$ /opt/wasi-sdk/bin/lldb # use LLDB from wasi-sdk release 32 or later
(lldb) process connect --plugin wasm connect://localhost:1234
Process 1 stopped
* thread #1, stop reason = signal SIGTRAP
frame #0: 0x40000000000001cc
-> 0x40000000000001cc: unreachable
0x40000000000001cd: end
0x40000000000001ce: local.get 0
0x40000000000001d0: call 13
(lldb) si
Process 1 stopped
* thread #1, stop reason = instruction step into
frame #0: 0x4000000000000184
-> 0x4000000000000184: block
0x4000000000000186: block
0x4000000000000188: global.get 1
0x400000000000018e: i32.const 3664
[ ... ]
```

This makes use of the `gdbstub` third-party crate, into which I've
upstreamed support for the Wasm extensions in daniel5151/gdbstub#188,
daniel5151/gdbstub#189, daniel5151/gdbstub#190, and
daniel5151/gdbstub#192. (I'll add vets as part of this PR.)

* cargo vets.

* Handle Trap events as well as breakpoints.

* Review feedback.

* Fix gdbstub artifact build to make it publishable (by disabling it when isolated crates are used).

* Review feedback.

* fix published-crates list

* For now, empty gdbstub data but no compile error when artifact crate is published.

* add some more Cargo metadata: version for artifact crate dep

show more ...

Merge the wasi-tls crates into a single one with feature flags (#12780)

prtest:full

Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT wor

Debugging: add the debug-main world. (#12756)

* Debugging: add the debug-main world.

This PR "draws the rest of the owl" for the debug-main
world (bytecodealliance/rfcs#45). This includes a WIT world that hosts
debug components that have access to "host debug powers" via a
debugging API, and the ability to load such a debug-component and give
it control of the main program as a debuggee when using `wasmtime
run`.

The WIT is namespaced to `bytecodealliance:wasmtime` and is slightly
aspirational in places: for example, the host does not yet implement
injection of early return values or exception-throws. I intend to fill
out a series of TODO issues once this all lands to track followup
("post-MVP") work.

This PR does not include any debug components. I separately have a
gdbstub component, with which I tested and co-developed this host-side
implementation. My plan is to land it in a followup PR as a component
that will be embedded in/shipped with the Wasmtime CLI and available
under an easy-to-use CLI option. Once we have that gdbstub component,
we can also implement end-to-end integration tests that boot up LLDB
and run through an expected interaction. (Separately, those
integration tests will require a release of wasi-sdk to ship an LLDB
binary that we can use.) As such, there are no real tests in this PR:
interesting behaviors only really occur with a full end-to-end flow.

The integration with the CLI is a little awkward (we internally build
another `wasmtime run` command that invokes the debug component, and
tie it together with the debuggee via a special `invoke_debugger` API;
this seemed less bad than reworking all of the WASI setup to be more
reusable). Happy to take more ideas here.

* Review feedback.

* Review feedback.

* Review feedback: update vendor-wit.sh.

* Review feedback: -Ddebugger-arg= -> -Darg=.

* Review feedback.

* Review feedback.

* Review feedback: factor host.rs into several submodules.

* Review feedback: rename Debugger to Debuggee on host side.

* Review feedback: split inherit_stdin_stdout, and add corresponding options for the debug component.

* Review feedback.

* Review feedback.

* Add simple debug-component tests.

* Add wasm32-wasip2 target in a few places in CI

* Cargo vets for wstd dependency.

* Add wasm32-wasip2 in more places

* fix debug-component test dependence on componentization byte offsets

* Review feedback.

* Fix cancel-safety of EventFuture.

* Fix: Interrupted events should only occur after interrupt(), not on every epoch yield.

* Review feedback.

* Review feedback: strip down WASI imports in debugger world.

* fold debugger test component back into wasip1 + adapter test artifact compilation flow

show more ...

Update more github actions (#12775)

Missed in the prior update...

Update some github actions versions (#12762)

CI is warning us about these, so try updating.

Refactor WASIp2 `wasi:http` implementation (#12748)

* Sequester WASIp2 in `wasmtime-wasi-http` to a module

This mirrors the `wasmtime-wasi` crate's organization where there's a
`p2` module and a `

Refactor WASIp2 `wasi:http` implementation (#12748)

* Sequester WASIp2 in `wasmtime-wasi-http` to a module

This mirrors the `wasmtime-wasi` crate's organization where there's a
`p2` module and a `p3` module at the top level.

* Refactor WASIp2 `wasi:http` implementation

This commit reorganizes and refactors the WASIp2 implementation of
`wasi:http` to look more like other `wasmtime-wasi`-style interfaces.
Specifically the old `WasiHttpImpl<T>` structure is removed in favor of
as `WasiHttpCtxView<'_>` type that is used to implement
bindgen-generated `Host` traits. This necessitated reorganizing the
methods of the previous `WasiHttpView` trait like so:

* The `WasiHttpView` trait is renamed to `WasiHttpHooks` to make space
for a new `WasiHttpView` which behaves like `WasiView`, for example.

* The `ctx` and `table` methods of `WasiHttpHooks` were removed since
they'll be fields in `WasiHttpCtxView`.

* Helper methods for WASIp2 were moved to methods on `WasiHttpCtxView`
instead of default methods on `WasiHttpHooks`.

With these changes in place the WASIp3 organization was also updated
slightly as well. Notably WASIp3 now contains a reference to the crate's
`WasiHttpCtx` structure (which has field limits for example). WASIp3's
previous `WasiHttpCtx` trait is now renamed to `WasiHttpHooks` as well.
This means that there are two `WasiHttpHooks` traits right now, one for
WASIp2 and one for WASIp3. In the future I would like to unify these two
but that will require some more work around the default `send_request`.

A final note here is that the `WasiHttpHooks` trait previously, and
continues to be, optional for embedders to implement. Default functions
are provided as `wasmtime_wasi_http::{p2, p3}::default_hooks`.
Additionally there's a `Default for &mut dyn WasiHttpHooks`
implementation, too.

With all that outlined: the motivation for this change is to bring the
WASIp2 and WASIp3 implementations of `wasi:http` closer together. This
is inspired by refactorings I was doing for #12674 to apply the same
header limitations for WASIp3 as is done for WASIp2. Prior to this
change there were a number of differences such as WASIp3 not having
`crate::WasiHttpCtx` around, WASIp2 having a different organization of
structures/borrows, etc. The goal is to bring the two implementations
closer in line with each other to make refactoring across them more
consistent and easier.

* Make `WasiHttp` in WASIp2 public

* Fix some conditional build

* Fix some doctests

* Fix configured build

* Fixup documentation

show more ...

Allow using `demangle` feature in `no_std` builds. (#12740)

While there, add `async`, `debug`, `debug-builtins` and `anyhow` to
the list of features supporting `#![no_std]`, and update the CI job
to

Allow using `demangle` feature in `no_std` builds. (#12740)

While there, add `async`, `debug`, `debug-builtins` and `anyhow` to
the list of features supporting `#![no_std]`, and update the CI job
to include those features.

Signed-off-by: Piotr Sikora <[email protected]>

show more ...

chore: bump to wasi 0.3.0-rc-2026-02-09 (#12557)

Update to wasi-sdk-30 in CI (#12495)

Testing it out and keeping it up-to-date

prtest:full

Switch back to emulation of s390x tests (#12491)

* Switch back to emulation of s390x tests

Recent changes looks like it's triggering some sort of bug to cancel all
our workflows without actually ru

Switch back to emulation of s390x tests (#12491)

* Switch back to emulation of s390x tests

Recent changes looks like it's triggering some sort of bug to cancel all
our workflows without actually running anything. Avoid the s390x runners
for now.

* Pin wkg used in CI

show more ...

fix: skip importing `std::path::Path` regardless of `cache` feature (#12479)

Signed-off-by: Ho Kim <[email protected]>

Pin fuzz build in CI to oss-fuzz's Rust version (#12459)

We updated our MSRV recently and that broke the build on OSS-Fuzz. To
avoid this happening again set things up in CI to ensure that this
does

Pin fuzz build in CI to oss-fuzz's Rust version (#12459)

We updated our MSRV recently and that broke the build on OSS-Fuzz. To
avoid this happening again set things up in CI to ensure that this
doesn't happen again without informing us we should update OSS-Fuzz
first.

show more ...

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

Fold the `wasmtime-error` crate into `wasmtime-core` (#12418)

Similar to #12398 and #12407 the idea is that all our dependency-free
(mostly) data structures and foundational data-types are in one lo

Fold the `wasmtime-error` crate into `wasmtime-core` (#12418)

Similar to #12398 and #12407 the idea is that all our dependency-free
(mostly) data structures and foundational data-types are in one location
to centralize testing, ergonomics, documentation, idioms, etc.

show more ...

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

Introduce `wasmtime_environ::collections::{OomArc, OomBox}` (#12361)

* Introduce `wasmtime_environ::collections::{OomArc, OomBox}`

These types mirror their `std`/`alloc` counterparts, but only prov

Introduce `wasmtime_environ::collections::{OomArc, OomBox}` (#12361)

* Introduce `wasmtime_environ::collections::{OomArc, OomBox}`

These types mirror their `std`/`alloc` counterparts, but only provide fallible
constructors and properly handle OOM by returning `Err(OutOfMemory)`.

Note that stable Rust doesn't actually give us any method to build fallible
allocation for `Arc<T>`, and we do not wish to fork `Arc<T>` since it is full of
very subtle unsafe code, so `OomArc::new` is only actually fallible in practice
when using nightly Rust and setting `RUSTFLAGS="--cfg arc_try_new"` during the
build. We use a custom `cfg`, rather than a cargo feature, so that `cargo test
--all-features --workspace` (which is morally what CI does) continues to Just
Work in the workspace, same as we do for e.g. Pulley's usage of the nightly Rust
tail calls feature.

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

* Avoid unused import warning in certain build configs

* Remove `out_of_line_slow_path!` macro

* Use extension traits for fallible `Arc<T>` and `Box<T>` allocation

Instead of defining new wrapper types around them.

* Fix example in docs

show more ...

fix `cargo test wasmtime-wasi-http --no-default-features --features p3` (#12380)

Recently, the above stopped building. This fixes the damage and adds CI
coverage.

Switch to using `wkg` for most WIT vendoring (#12327)

* feat(p3)!: vendor 0.3.0-rc-2026-01-06

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wk

Switch to using `wkg` for most WIT vendoring (#12327)

* feat(p3)!: vendor 0.3.0-rc-2026-01-06

Update wasmtime's WASI implementation from version
0.3.0-rc-2025-09-16 to 0.3.0-rc-2026-01-06, using wkg for WIT vendoring.

This involves API changes in clocks and HTTP.

* ci: install wkg in monolith_checks

* Revert back to original WIT versions

Also refactor the script a bit to avoid too bash-isms and hopefully make
it a bit more straightforward what's happening.

---------

Co-authored-by: Bailey Hayes <[email protected]>

show more ...

wasmtime-wizer: make rayon optional (#12313)

* wasmtime-wizer: make rayon optional

when compiling wasmtime-wizer to wasm32, rayon detects that and tries to
use wasm-bindgen APIs

the new rayon feat

wasmtime-wizer: make rayon optional (#12313)

* wasmtime-wizer: make rayon optional

when compiling wasmtime-wizer to wasm32, rayon detects that and tries to
use wasm-bindgen APIs

the new rayon feature flag allows users to choose if snapshotting should
be parallel or sequential

* add the new wasmtime-wizer rayon feature flag to CI micro_checks

show more ...

wasi-tls: Add OpenSSL backend (#12228)

* Create an OpenSSL backend for wasi-tls

* vet wasmtime-wasi-tls-openssl

* Add more vets

---------

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