|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6 |
|
| #
c8764ed0 |
| 18-Feb-2026 |
Adam Bratschi-Kaye <[email protected]> |
Limit the number of frames in backtrace collection (#12542)
* Limit the number of frames in backtrace collection
Add `Config::wasm_backtrace_max_frames` option to limit the number of frames collect
Limit the number of frames in backtrace collection (#12542)
* Limit the number of frames in backtrace collection
Add `Config::wasm_backtrace_max_frames` option to limit the number of frames collected in backtraces and set the default at 20. This helps prevent expensive work from very deep call stacks.
Setting the value to 0 is the same as disabling backtraces and so this change deprecates `Config::wasm_backtrace`.
Addresses https://github.com/bytecodealliance/wasmtime/issues/5052
* review comments
* fix tests
* formatting
* fix stack overflow test
* fix docs and fuzzing
* configure backtraces when fuzzing
show more ...
|
|
Revision tags: v41.0.3, v41.0.2 |
|
| #
bc4582c3 |
| 27-Jan-2026 |
Alex Crichton <[email protected]> |
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 ...
|
|
Revision tags: v41.0.1, v36.0.5, v40.0.3, v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1 |
|
| #
96e19700 |
| 07-Jan-2026 |
Nick Fitzgerald <[email protected]> |
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 ...
|
|
Revision tags: v40.0.0 |
|
| #
99ecf728 |
| 03-Dec-2025 |
Chris Fallin <[email protected]> |
Debug: create private code memories per store when debugging is enabled. (#12051)
* Debug: create private code memories per store when debugging is enabled.
This will allow patching code to implem
Debug: create private code memories per store when debugging is enabled. (#12051)
* Debug: create private code memories per store when debugging is enabled.
This will allow patching code to implement e.g. breakpoints. (That is, for now the copies are redundant, but soon they will not be.)
This change follows the discussion [here] and offline to define a few types that better encapsulate the distinction we want to enforce. Basically, there is almost never a bare `CodeMemory`; they are always wrapped in an `EngineCode` or `StoreCode`, the latter being a per-store instance of the former. Accessors are moved to the relevant place so that, for example, one cannot get a pointer to a Wasm function's body without being in the context of a `Store` where the containing module has been registered. The registry then returns a `ModuleWithCode` that boxes up a `Module` reference and `StoreCode` together for cases where we need both the metadata from the module and the raw code to derive something.
The only case where we return raw code pointers to the `EngineCode` directly have to do with Wasm-to-array trampolines: in some cases, e.g. `InstancePre` pre-creating data structures with references to host functions, it breaks our expected performance characteristics to make the function pointers store-specific. This is fine as long as the Wasm-to-array trampolines never bake in direct calls to Wasm functions; the strong invariant is that Wasm functions never execute from `EngineCode` directly. Some parts of the component runtime would also have to be substantially refactored if we wanted to do away with this exception.
The per-`Store` module registry is substantially refactored in this PR. I got rid of the modules-without-code distinction (the case where a module only has trampolines and no defined functions still works fine), and organized the BTreeMaps to key on start address rather than end address, which I find a little more intuitive (one then queries with the dual to the range -- 0-up-to-PC and last entry found).
[here]: https://github.com/bytecodealliance/wasmtime/pull/12051#pullrequestreview-3493711812
* Review feedback: do not assume a reasonable code alignment; error when it cannot be known
* Review feedback: fail properly in profiler when we are cloning code
* Fix guest-profiler C API.
* Review feedback: make private-code representation impossible in non-debugging-support builds.
* Add TODO comment referencing issue for cloning only .text.
* clang-format
* Review feedback: add back Component::image_range.
* Review feedback: error on registering profiling metadata when debug is enabled.
* rustfmt
* Remove early bail on profiling-data registration when debugging is enabled: this always happens so we cannot error out.
show more ...
|
|
Revision tags: v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1, v37.0.2, v37.0.1, v37.0.0 |
|
| #
1806c265 |
| 15-Sep-2025 |
Nick Fitzgerald <[email protected]> |
Lookup functions in the text section by `FuncKey` at runtime (#11630)
This commit refactors our metadata, treating compiled functions homogeneously and removing the need to add new tables to places
Lookup functions in the text section by `FuncKey` at runtime (#11630)
This commit refactors our metadata, treating compiled functions homogeneously and removing the need to add new tables to places like `CompiledModuleInfo` whenever we add a new kind of function. This also simplifies the process of constructing the metadata for a final, linked compilation artifact. Finally, it paves the way to doing gc-sections during our linking process (which would give us smaller code sizes by removing functions that have been inlined into every caller, for example) as we now allow holes in certain types of function index spaces that were previously always densely populated.
We have two kinds of index spaces:
1. Mostly-dense index spaces, which take O(max_index) space and provide O(1) lookups.
2. Sparse index spaces, which take O(num_members) space and provide O(log n) lookups.
Most of our function index spaces are currently dense, but we can tweak that in the future if necessary.
Furthermore, code size of `.cwasm` binaries has shrunk very slightly with this refactoring. Consider `spidermonkey.wasm`'s compiled `.cwasm`:
* Size before: 218756 `.wasmtime.info` section bytes, 20052632 total bytes * Size after: 213761 `.wasmtime.info` section bytes, 20047640 total bytes
That is a 2.28% reduction on the size of the `.wasmtime.info` section, or a 0.025% reduction total.
However, we previously did a single metadata lookup to get the location of both a Wasm function itself and its array-to-Wasm trampoline at the same time, and in the new version of the code two lookups are performed. This is slightly slower, as shown in our call-indirect micro-benchmark that combines lazy table initialization (which delays looking up the function element's location until runtime) with indirect-calling each table element exactly once (which defeats the amortization of that lookup). So this micro-benchmark is both synthetic and the worst-case scenario for this commit's change: we are measuring, as much as we can, *only* the force-initialization-of-a-lazy-funcref-table-slot path.
Ultimately, I believe that the simplification is worth the regression in this micro-benchmark.
<details>
<summary>call-indirect micro-benchmarks results</summary>
``` call-indirect/same-callee/table-init-lazy/65536-calls time: [152.77 µs 154.92 µs 157.39 µs] thrpt: [416.40 Melem/s 423.04 Melem/s 428.99 Melem/s] change: time: [−13.749% −10.205% −6.2864%] (p = 0.00 < 0.05) thrpt: [+6.7081% +11.365% +15.941%] Performance has improved. Found 13 outliers among 100 measurements (13.00%) 8 (8.00%) high mild 5 (5.00%) high severe call-indirect/different-callees/table-init-lazy/65536-calls time: [4.3564 ms 4.4641 ms 4.5843 ms] thrpt: [14.296 Melem/s 14.681 Melem/s 15.044 Melem/s] change: time: [+38.134% +44.404% +50.927%] (p = 0.00 < 0.05) thrpt: [−33.743% −30.750% −27.606%] Performance has regressed. Found 5 outliers among 100 measurements (5.00%) 2 (2.00%) high mild 3 (3.00%) high severe call-indirect/same-callee/table-init-strict/65536-calls time: [144.91 µs 148.41 µs 152.02 µs] thrpt: [431.10 Melem/s 441.58 Melem/s 452.24 Melem/s] change: time: [−13.665% −10.470% −7.2626%] (p = 0.00 < 0.05) thrpt: [+7.8313% +11.694% +15.828%] Performance has improved. Found 4 outliers among 100 measurements (4.00%) 1 (1.00%) high mild 3 (3.00%) high severe call-indirect/different-callees/table-init-strict/65536-calls time: [195.18 µs 200.67 µs 206.49 µs] thrpt: [317.38 Melem/s 326.59 Melem/s 335.77 Melem/s] change: time: [−15.936% −11.568% −7.0835%] (p = 0.00 < 0.05) thrpt: [+7.6235% +13.081% +18.957%] Performance has improved. Found 5 outliers among 100 measurements (5.00%) 5 (5.00%) high mild ```
</details>
show more ...
|
|
Revision tags: v36.0.2, v36.0.1 |
|
| #
2d25f862 |
| 21-Aug-2025 |
Chris Fallin <[email protected]> |
WebAssembly exception-handling support. (#11326)
* WebAssembly exception-handling support.
This PR introduces support for the [Wasm exception-handling proposal], which introduces a conventional try
WebAssembly exception-handling support. (#11326)
* WebAssembly exception-handling support.
This PR introduces support for the [Wasm exception-handling proposal], which introduces a conventional try/catch mechanism to WebAssembly. The PR supports modules that use `try_table` to register handlers for a lexical scope; and provides `throw` and `throw_ref` that allocate (in the first case) and throw exception objects.
This PR builds on top of the work in #10510 for Cranelift-level exception support, #10919 for an unwinder, and #11230 for exception objects built on top of GC, in addition a bunch of smaller fix and enabling PRs around those.
[Wasm exception-handling proposal]: https://github.com/WebAssembly/exception-handling/
prtest:full
* Permit UnwindToWasm to have unused fields in Pulley builds (for now).
* Resolve miri-caught reborrowing issue.
* Ignore exceptions tests in miri for now (Pulley not supported).
* Use wasmtime_test on exceptions tests.
* Get tests passing on pulley platforms
* Add a check to `supports_host` for the generated test and assert failure also when that is false. * Remove `pulley_unsupported` test as it falls out of `#[wasmtime_test]` * Remove `exceptions_store` helper as it falls out of `#[wasmtime_test]` * Remove miri annotations as they fall out of `#[wasmtime_test]`
* Remove dead import
* Skip some unsupported tests entirely in `#[wasmtime_test]`
If the selected compiler doesn't support the host at all then there's no need to run it. Actually running it could misinterpret `CraneliftNative` as "run with pulley" otherwise, so avoid such false negatives.
* Cranelift: dynamic contexts: account for outgoing-args area.
---------
Co-authored-by: Alex Crichton <[email protected]>
show more ...
|
|
Revision tags: v36.0.0, v35.0.0, v24.0.4, v33.0.2, v34.0.2 |
|
| #
838ed2d0 |
| 07-Jul-2025 |
Alex Crichton <[email protected]> |
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 ...
|
|
Revision tags: v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0, v33.0.0 |
|
| #
90ac295e |
| 19-May-2025 |
Alex Crichton <[email protected]> |
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 ...
|
|
Revision tags: v32.0.0 |
|
| #
58ad9115 |
| 04-Apr-2025 |
Alex Crichton <[email protected]> |
Update how traps are rendered (#10523)
* Add 2 more columns to the default address width. * Print newlines between inline symbols which accidentally weren't present.
|
| #
8385bea2 |
| 31-Mar-2025 |
Alex Crichton <[email protected]> |
Adjust hints about using `WASMTIME_BACKTRACE_DETAILS` (#10498)
This commit updates some infrastructure to hint that `WASMTIME_BACKTRACE_DETAILS` can be used to show more detail in backtraces. Notabl
Adjust hints about using `WASMTIME_BACKTRACE_DETAILS` (#10498)
This commit updates some infrastructure to hint that `WASMTIME_BACKTRACE_DETAILS` can be used to show more detail in backtraces. Notably this warning is suppressed if `feature = "std"` is turned off or if `feature = "addr2line"` is turned off since both are required.
show more ...
|
| #
452086fb |
| 20-Mar-2025 |
Alex Crichton <[email protected]> |
Store stack maps in an ELF section (#10404)
* Store stack maps in an ELF section
This commit moves the storage of stack maps from being embedded within serde-encoded information to instead being st
Store stack maps in an ELF section (#10404)
* Store stack maps in an ELF section
This commit moves the storage of stack maps from being embedded within serde-encoded information to instead being stored in a separate ELF section in the final executable. The motivation for this is to make this more easily debuggable with a `wasmtime objdump` command in the future but this additionally should have the nice side effect of making non-stack-maps modules have smaller encoded information (no need to encode an empty list) and additionally make stack-maps-using-modules faster to decode (no serde decoding, it's already "decoded").
This implements a scheme similar to the address map section where there's a "builder" for the section and then a separate half to decode the section. The same basic encoding, a bit map, is used. This is likely going to make accessing stack maps slightly slower, but if that's an issue we can tweak the representation and align things and/or use `usize` or such.
* Update crates/environ/src/compile/stack_maps.rs
Co-authored-by: Andrew Brown <[email protected]>
* Review comments
* More review comments
* Fix MIRI test by enabling `unaligned` object feature
---------
Co-authored-by: Andrew Brown <[email protected]>
show more ...
|
|
Revision tags: v31.0.0, v30.0.2, v30.0.1, v30.0.0, v29.0.1, v29.0.0, v28.0.1, v28.0.0 |
|
| #
07eeac40 |
| 06-Dec-2024 |
Alex Crichton <[email protected]> |
Implement custom stack unwinding for Pulley (#9758)
* Implement custom stack unwinding for Pulley
The pulley calling convention may not match the native calling convention, which is the case for s3
Implement custom stack unwinding for Pulley (#9758)
* Implement custom stack unwinding for Pulley
The pulley calling convention may not match the native calling convention, which is the case for s390x, so the unwinding that Wasmtime does needs to be parameterized over what's being unwound. This commit adds a new `Unwind` trait with various methods behind it that the backtrace implementation is then updated to use.
* Fix alignment check for 32-bit
show more ...
|
| #
70a37939 |
| 06-Dec-2024 |
Alex Crichton <[email protected]> |
Support executing Pulley in Wasmtime (#9744)
* Support executing Pulley in Wasmtime
This commit is the initial implementation of executing the Pulley interpreter from the `wasmtime` crate. This gi
Support executing Pulley in Wasmtime (#9744)
* Support executing Pulley in Wasmtime
This commit is the initial implementation of executing the Pulley interpreter from the `wasmtime` crate. This gives access to all of the `wasmtime` crate's runtime APIs backed by execution of bytecode in Pulley. This builds on the previous PRs I've been making for support in Pulley to culminate in testing on CI in this PR. This PR handles some final tidbits related to producing a runnable image that can be interpreted by the `wasmtime` crate such as:
* Pulley compilation artifacts are no longer marked as natively executable, just read-only. * Pulley compilation artifacts include wasm-to-array trampolines like normal platforms (removes a pulley special-case). * Dispatch of host calls from Pulley to the Wasmtime runtime are implemented. * Pulley's list of panicking wasm features is slimmed down as most are covered by "this lowering isn't supported" errors. * Execution of wasm code now has an `if` to see whether Pulley is enabled within a `Store` or not. * Traps and basic "unwinding" of the pulley stack are implemented (e.g. a "pulley version" of `setjmp` and `longjmp`, sort of) * Halting the interpreter has been refactored to help shrink the size of `ControlFlow<Done>` and handle metadata with each done state.
Some minor refactorings are also included here and there along with a few fixes here and there necessary to get tests passing.
The next major part of this commit is updates to our `wast` test suite and executing all `*.wast` files. Pulley is now executed by default for all files as a new execution engine. This means that all platforms in CI will start executing Pulley tests. At this time almost all tests are flagged as "expected to fail" but there are a small handful of allow-listed tests which are expected to pass. This exact list will change over time as CLIF lowerings are implemented and the interpreter is extended.
Follow-up PRs will extend the testing strategy further such as:
* Extending `#[wasmtime_test]` to include Pulley in addition to Winch. * Getting testing set up on CI for 32-bit platforms.
prtest:full
* Fix pulley fuzz build
* Fix clippy lints
* Shuffle around some `#[cfg]`'d code
* Remove unused imports
* Update feature sets testing MIRI
Enable pulley for wasmtime/wasmtime-cli and also enable all features for wasmtime-environ
* Round up pulley's page size to 64k
* Skip pulley tests on s390x for now
* Add a safety rail for matching a pulley target to the host
* Fix more pulley tests on s390x
* Review comments
* Fix fuzz build
show more ...
|
| #
9034e101 |
| 03-Dec-2024 |
Alex Crichton <[email protected]> |
Rely on `core::error::Error` (#9702)
* Rely on `core::error::Error`
With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is available which means that in `no_std` mode the `Error`
Rely on `core::error::Error` (#9702)
* Rely on `core::error::Error`
With Wasmtime's new MSRV at 1.81 this means that `core::error::Error` is available which means that in `no_std` mode the `Error` trait can be used. This has been integrated into `anyhow::Error` already upstream and means that we can remove our own local hacks such as the `Err2Anyhow` trait.
This commit removes the `Err2Anyhow` trait and all usage, going back to idiomatic Rust error propagation and conversion even in the `no_std` world. This should make code more portable by default and remove some weird idioms we had for supporting this.
prtest:full
* Add some trusted vets
* Audit object crate update
* Disable backtraces on CI
show more ...
|
| #
6c97d5e6 |
| 25-Nov-2024 |
Alex Crichton <[email protected]> |
Simplify some trap handling in `wasmtime` runtime (#9673)
The `needs_backtrace` field on `TrapReason` is an old artifact of having the `wasmtime` and `wasmtime-runtime` crates split and there's no l
Simplify some trap handling in `wasmtime` runtime (#9673)
The `needs_backtrace` field on `TrapReason` is an old artifact of having the `wasmtime` and `wasmtime-runtime` crates split and there's no longer any need for that. This commit removes the field and directly queries it from the error as necessary when capturing backtraces.
show more ...
|
|
Revision tags: v27.0.0 |
|
| #
d3132c9d |
| 19-Nov-2024 |
Alex Crichton <[email protected]> |
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `si
Add a `signals-based-traps` Cargo compile-time feature (#9614)
* Gate signal handlers behind a new Cargo feature
This commit adds a new on-by-default Cargo feature to the `wasmtime` crate named `signals-based-traps`. This is modeled after the `Config::signals_based_traps` configuration at runtime and can be used to statically disable the use of signal handlers in Wasmtime. This notably reduces the number of platform dependencies that Wasmtime has and provides a mode of avoiding relying on signals altogether.
This introduces a new `MallocMemory` which is a linear memory backed by the system allocator. This new type of memory is enabled when virtual memory guards are disabled and signals-based-traps are disabled. This means that this new type of memory will be candidate for fuzzing for example.
prtest:full
* Fix rebase conflict
* Refactor `MmapVec` documentation and representation
* Remove no-longer-needed `Arc` * Document it may be backed by `Vec<u8>`
show more ...
|
|
Revision tags: v26.0.1, v25.0.3, v24.0.2, v26.0.0, v21.0.2, v22.0.1, v23.0.3, v25.0.2, v24.0.1, v25.0.1, v25.0.0 |
|
| #
0bce0968 |
| 06-Sep-2024 |
Alex Crichton <[email protected]> |
Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)
* Warn against `clippy::cast_possible_truncation` in Wasmtime
This commit explicitly enables the `clippy::cast_possible_truncatio
Warn against `clippy::cast_possible_truncation` in Wasmtime (#9209)
* Warn against `clippy::cast_possible_truncation` in Wasmtime
This commit explicitly enables the `clippy::cast_possible_truncation` lint in Clippy for just the `wasmtime::runtime` module. This does not enable it for the entire workspace since it's a very noisy lint and in general has a low signal value. For the domain that `wasmtime::runtime` is working in, however, this is a much more useful lint. We in general want to be very careful about casting between `usize`, `u32`, and `u64` and the purpose of this module-targeted lint is to help with just that. I was inspired to do this after reading over #9206 where especially when refactoring code and changing types I think it would be useful to have locations flagged as "truncation may happen here" which previously weren't truncating.
The failure mode for this lint is that panics might be introduced where truncation is explicitly intended. Most of the time though this isn't actually desired so the more practical consequence of this lint is to probably slow down wasmtime ever so slightly and bloat it ever so slightly by having a few more checks in a few places. This is likely best addressed in a more comprehensive manner, however, rather than specifically for just this one case. This problem isn't unique to just casts, but to many other forms of `.unwrap()` for example.
* Fix some casts in tests
show more ...
|
|
Revision tags: v24.0.0, v23.0.2 |
|
| #
a0442ea0 |
| 05-Aug-2024 |
Hamir Mahal <[email protected]> |
Enforce `uninlined_format_args` for the workspace (#9065)
* Enforce `uninlined_format_args` for the workspace
* fix: failing `Monolith Checks` job
* fix: formatting
|
|
Revision tags: v23.0.1, v23.0.0, v22.0.0 |
|
| #
1512a954 |
| 14-Jun-2024 |
Nick Fitzgerald <[email protected]> |
Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)
* Add `anyhow` stuff to our internal `wasmtime` crate prelude
We use it basically everywhere and it is annoying to have to import
Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)
* Add `anyhow` stuff to our internal `wasmtime` crate prelude
We use it basically everywhere and it is annoying to have to import.
I also did an audit of existing `use` statements and removed the now-redundant ones and replaced one-off imports with usage of the prelude, so that the prelude is available by default in more places.
* Fix `cargo doc`
show more ...
|
|
Revision tags: v21.0.1, v21.0.0, v20.0.2 |
|
| #
81a89169 |
| 04-May-2024 |
Alex Crichton <[email protected]> |
Add support for `#![no_std]` to the `wasmtime` crate (#8533)
* Always fall back to custom platform for Wasmtime
This commit updates Wasmtime's platform support to no longer require an opt-in `RUSTF
Add support for `#![no_std]` to the `wasmtime` crate (#8533)
* Always fall back to custom platform for Wasmtime
This commit updates Wasmtime's platform support to no longer require an opt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becoming officially supported this should provide a better onboarding experience where the fallback custom platform is used. This will cause linker errors if the symbols aren't implemented and searching/googling should lead back to our docs/repo (eventually, hopefully).
* Change Wasmtime's TLS state to a single pointer
This commit updates the management of TLS to rely on just a single pointer rather than a pair of a pointer and a `bool`. Additionally management of the TLS state is pushed into platform-specific modules to enable different means of managing it, namely the "custom" platform now has a C function required to implement TLS state for Wasmtime.
* Delay conversion to `Instant` in atomic intrinsics
The `Duration` type is available in `no_std` but the `Instant` type is not. The intention is to only support the `threads` proposal if `std` is active but to assist with this split push the `Duration` further into Wasmtime to avoid using a type that can't be mentioned in `no_std`.
* Gate more parts of Wasmtime on the `profiling` feature
Move `serde_json` to an optional dependency and gate the guest profiler entirely on the `profiling` feature.
* Refactor conversion to `anyhow::Error` in `wasmtime-environ`
Have a dedicated trait for consuming `self` in addition to a `Result`-friendly trait.
* Gate `gimli` in Wasmtime on `addr2line`
Cut down the dependency list if `addr2line` isn't enabled since then the dependency is not used. While here additionally lift the version requirement for `addr2line` up to the workspace level.
* Update `bindgen!` to have `no_std`-compatible output
Pull most types from Wasmtime's `__internal` module as the source of truth.
* Use an `Option` for `gc_store` instead of `OnceCell`
No need for synchronization here when mutability is already available in the necessary contexts.
* Enable embedder-defined host feature detection
* Add `#![no_std]` support to the `wasmtime` crate
This commit enables compiling the `runtime`, `gc`, and `component-model` features of the `wasmtime` crate on targets that do not have `std`. This tags the crate as `#![no_std]` and then updates everything internally to import from `core` or `alloc` and adapt for the various idioms. This ended up requiring some relatively extensive changes, but nothing too too bad in the grand scheme of things.
* Require `std` for the perfmap profiling agent
prtest:full
* Fix build on wasm
* Fix windows build
* Remove unused import
* Fix Windows/Unix build without `std` feature
* Fix some doc links
* Remove unused import
* Fix build of wasi-common in isolation
* Fix no_std build on macos
* Re-fix build
* Fix standalone build of wasmtime-cli-flags
* Resolve a merge conflict
* Review comments
* Remove unused import
show more ...
|
|
Revision tags: v20.0.1 |
|
| #
72004aad |
| 30-Apr-2024 |
Nick Fitzgerald <[email protected]> |
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)
* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate
* Rewrite uses of `wasmtime
Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)
* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate
* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`
* Remove dep on `wasmtime-runtime` from `wasmtime-cli`
* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module
* Update labeler for merged crates
* Fix `publish verify`
prtest:full
show more ...
|
|
Revision tags: v20.0.0, v17.0.3, v19.0.2, v18.0.4, v19.0.1, v19.0.0 |
|
| #
c4c5ee5a |
| 18-Mar-2024 |
Alex Crichton <[email protected]> |
Don't lookup trap codes twice on traps (#8150)
* Don't lookup trap codes twice on traps
Currently whenever a signal or trap is handled in Wasmtime we perform two lookups of the trap code. One durin
Don't lookup trap codes twice on traps (#8150)
* Don't lookup trap codes twice on traps
Currently whenever a signal or trap is handled in Wasmtime we perform two lookups of the trap code. One during the trap handling itself to ensure we can handle the trap, and then a second once the trap is handled. There's not really any need to do two here, however, as the result of the first can be carried over to the second.
While I was here refactoring things I also changed how some return values are encoded, such as `take_jmp_buf_if_trap` now returns a more self-descriptive enum.
* Fix dead code warning on MIRI
* Update crates/environ/src/trap_encoding.rs
Co-authored-by: bjorn3 <[email protected]>
* Fix min-platform build
---------
Co-authored-by: bjorn3 <[email protected]>
show more ...
|
|
Revision tags: v18.0.3, v18.0.2, v17.0.2 |
|
| #
9ce3ffe1 |
| 22-Feb-2024 |
Alex Crichton <[email protected]> |
Update some CI dependencies (#7983)
* Update some CI dependencies
* Update to the latest nightly toolchain * Update mdbook * Update QEMU for cross-compiled testing * Update `cargo nextest` for usag
Update some CI dependencies (#7983)
* Update some CI dependencies
* Update to the latest nightly toolchain * Update mdbook * Update QEMU for cross-compiled testing * Update `cargo nextest` for usage with MIRI
prtest:full
* Remove lots of unnecessary imports
* Downgrade qemu as 8.2.1 seems to segfault
* Remove more imports
* Remove unused winch trait method
* Fix warnings about unused trait methods
* More unused imports
* More unused imports
show more ...
|
|
Revision tags: v18.0.1, v18.0.0, v17.0.1 |
|
| #
d4242001 |
| 29-Jan-2024 |
Adam Bratschi-Kaye <[email protected]> |
Support compilation-only build by adding a `runtime` feature (#7766)
* Add `runtime` feature to `wasmtime` crate
This feature can be disabled to build `wasmtime` only for compilation. This can be u
Support compilation-only build by adding a `runtime` feature (#7766)
* Add `runtime` feature to `wasmtime` crate
This feature can be disabled to build `wasmtime` only for compilation. This can be useful when cross-compiling, especially on a target that can't run wasmtime itself (e.g. `wasm32`).
* prtest:full
* don't round pages without runtime feature
* fix async assertions
* move profiling into runtime
* enable runtime for wasmtime-wasi
* enable runtime for c-api
* fix build_artifacts in non-cache case
* fix miri extensions
* enable runtime for wast
* enable runtime for explorer
* support cranelift all-arch on wasm32
* add doc links for `WeakEngine`
* simplify lib runtime cfgs
* move limits and resources to runtime
* move stack to runtime
* move coredump and debug to runtime
* add runtime to coredump and async features
* add wasm32 build job
* combine engine modules
* single compile mod
* remove allow for macro paths
* add comments
show more ...
|