en Copyright 2015 Java http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/winch_engine_features.rs#94740588 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 List of files: /wasmtime-44.0.1/tests/all/winch_engine_features.rs Fri, 09 Jan 2026 19:15:48 +0000 Nick Fitzgerald <fitzgen@gmail.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/winch_engine_features.rs#02155232 Wasmtime: implement debug instrumentation and basic host API to examine runtime state. (#11769)* Wasmtime: implement debug instrumentation and basic host API to examine runtime state.This PR implements ideas from the [recent RFC] to serve as the basisfor Wasm (guest) debugging: it adds a stackslot to each functiontranslated from Wasm, stores to replicate Wasm VM state in thestackslot as the program runs, and metadata to describe the format ofthat state and allow reading it out at runtime.As an initial user of this state, this PR adds a basic "stack view"API that, from host code that has been called from Wasm, can examineWasm frames currently on the stack and read out all of their localsand stack slots.Note in particular that this PR does not include breakpoints,watchpoints, stepped execution, or any sort of user interface for anyof this; it is only a foundation.This PR still has a few unsatisfying bits that I intend to address:- The "stack view" performs some O(n) work when the view is initially taken, computing some internal data per frame. This is forced by the current design of `Backtrace`, which takes a closure and walks that closure over stack frames eagerly (rather than work as an iterator). It's got some impressive iterator-chain stuff going on internally, so refactoring it to the latter approach might not be *too* bad, but I haven't tackled it yet. A O(1) stack view, that is, one that does work only for frames as the host API is used to walk up the stack, is desirable because some use-cases may want to quickly examine e.g. only the deepest frame (say, running with a breakpoint condition that needs to read a particular local's value after each step).- It includes a new `Config::compiler_force_inlining()` option that is used only for testing that we get the correct frames after inlining. I couldn't get the existing flags to work on a Wasmtime config level and suspect there may be an existing bug there; I will try to split out a fix for it.This PR renames the existing `debug` option to `native_debug`, todistinguish it from the new approach.[recent RFC]: https://github.com/bytecodealliance/rfcs/pull/44* Update to new APIs on Cranelift side.* Test update.* Adjust objdump printing of InstPos on frame progpoints; and adjust progpoint collapsing.* Convert to iterator form.* Fix path in native-debug tests (debug -> native_debug rename).* Enforce that `debug_instrumentation` can only be enabled when feature is enabled.* Add missing assert.* Use builtin knob for forcing intra-module inlining instead.* Review feedback:- Make StackView own the current frame rather than handing it out. This prevents the current frame (`FrameView`) from walking away and hiding somewhere it shouldn't, to be used unsoundly later.- Assert no-GC during stack walk.* Merge debug-instrumentation hooks on FuncEnvironment into before/after hooks.* Review feedback: avoid downcasting funcs twice.* Add debug feature to `wasmtime` crate's defaults.* Review feedback: u32s for local and stack indices in debug host API.* Use *const u8 as stack pointers and `with_exposed_provenance` in debug API.* Remove some `srcloc` plumbing in Wasm translator.* Rename native-debug back to debug, and make the new thing "guest debugging".* rustfmt in debugging test.* fix disas test after guest-debug CLI option rename.* Review feedback: no separate debug-instrumentation hooks on FuncEnvironment.* Review feedback: update doc comment on `Config::guest_debug`.* Review feedback: rename `generate_debuginfo` to `debug_native` in tunables.* Review feedback: miscellaneous comments.* Review comment: fix wording in safety conditions.* revert wasi-common submodule update* Properly root values in debug frame slots.Fixes #11841.* Fix non-`debug`-feature build.* Review feedback: naming.* Ignore tests that compile modules in miri. List of files: /wasmtime-44.0.1/tests/all/winch_engine_features.rs Wed, 15 Oct 2025 00:03:52 +0000 Chris Fallin <chris@cfallin.org> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/winch_engine_features.rs#df725421 Simplify some conditional testing logic for Winch (#11166)* Simplify some conditional testing logic for WinchRun all tests on all platforms in `#[wasmtime_test]` for Winch without`#[cfg]` and use the result of `should_fail` to determine whether itshould fail or not (e.g. still expect failure on riscv64/s390x/etc).* Ignore non-Pulley tests on Miri List of files: /wasmtime-44.0.1/tests/all/winch_engine_features.rs Tue, 01 Jul 2025 22:42:30 +0000 Alex Crichton <alex@alexcrichton.com> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/winch_engine_features.rs#a6227aad Add Pulley support to wasmtime_test macro (#10057)* wasmtime_test: Rename "Cranelift" strategy to "CraneliftNative"* wasmtime_test: Add CraneliftPulley to default test strategies* wasmtime_test: Use one specific compilation strategy with `only` specifier.Tests in `tests/all/fuel.rs` and `tests/all/winch_engine_features.rs`were using `#[wasmtime_test(strategies(not(Cranelift)))]` to gate theirWinch specific tests. Now that there is a third compilation strategy,those tests were failing against Pulley.I've replaced those with `#[wasmtime_test(strategies(only(Winch)))]`to be more clear that they are targeted specifically at Winch.* wasmtime_test: Fix flaky `wrap_and_typed_i31ref` test in tests/all/func.rsThe `static HITS` variable was sharing state between tests,causing them to clobber each other when ran together. List of files: /wasmtime-44.0.1/tests/all/winch_engine_features.rs Tue, 21 Jan 2025 18:01:33 +0000 Taylor Hogge <taylor@irreducible.io> http://172.16.0.5:8080/history/wasmtime-44.0.1/tests/all/winch_engine_features.rs#6fdff5cd winch: Improve tunables/configuration validation (#9490)* winch: Improve tunables/configuration validationThis commit introduces proper validation and documentation to handle theengine features not currently supported by Winch (e.g., `consume_fuel`,follow-up to the discussion inhttps://github.com/bytecodealliance/wasmtime/pull/9472).In this commit, the tunables validation is done at the `set_tunables`method in Winch's `wasmtime_environ::compile::CompilerBuilder`implemetation, which enables removing Winch specific logic from`Config::validate`This change also introduces the question of how to consolidate thecompiler specific flags with Winch (e.g, the user-specified`cranelift_*` options) given that not all of them are applicable toWinch (e.g., `cranelift_debug_verifier`,`cranelift_nan_canonicalization`), this change doesn't introduce anyfunctionality on this front, however, it's probably something worthconsidering/discussing.* Update the fuzzers* Use `wasmtime_test` instead of testThis allows a couple of things:* Pre-configuring `Winch` as the strategy* Handling the target architetures supported by Winch List of files: /wasmtime-44.0.1/tests/all/winch_engine_features.rs Tue, 22 Oct 2024 17:37:11 +0000 Saúl Cabrera <saulecabrera@gmail.com>