Changes in stack_map.rs

a2cc11f3 - Update object to 0.39.0 (#12866)

Mon, 30 Mar 2026 09:35:59 +0000

Update object to 0.39.0 (#12866)* Update object to 0.39.0* Add vets for `object`---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

2bac6574 - Update the `log` dependency (#11197)

Mon, 07 Jul 2025 23:25:45 +0000

Update the `log` dependency (#11197)* Update the `log` dependencyThis enables getting warnings about formatting strings in the `log`crate directives which are then additionally fixed here as well.* Update dependency directive in `Cargo.toml` List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

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

Wed, 09 Apr 2025 21:06:59 +0000

Enable the `unsafe-op-in-unsafe-fn` lint (#10559)* Enable the `unsafe-op-in-unsafe-fn` lintThis commit enables the `unsafe-op-in-unsafe-fn` lint in rustc for theentire workspace. This lint will be warn-by-default in the 2024 editionso this is intended to smooth the future migration to the new edition.Many `unsafe` blocks were added in places the lint warned about, withtwo major exceptions. The `wasmtime` and `wasmtime-c-api` crates simplyexpect this lint to fire and effectively disable the lint. They're toobig at this time to do through this PR. My hope is that one day in thefuture they'll be migrated, but more realistically that probably won'thappen so these crates just won't benefit from this lint.* Fix nostd fiber buildprtest:full* Fix build on Windows* Fix asan build List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

452086fb - Store stack maps in an ELF section (#10404)

Thu, 20 Mar 2025 19:46:14 +0000

Store stack maps in an ELF section (#10404)* Store stack maps in an ELF sectionThis commit moves the storage of stack maps from being embedded withinserde-encoded information to instead being stored in a separate ELFsection in the final executable. The motivation for this is to make thismore easily debuggable with a `wasmtime objdump` command in the futurebut this additionally should have the nice side effect of makingnon-stack-maps modules have smaller encoded information (no need toencode an empty list) and additionally make stack-maps-using-modulesfaster to decode (no serde decoding, it's already "decoded").This implements a scheme similar to the address map section wherethere's a "builder" for the section and then a separate half to decodethe section. The same basic encoding, a bit map, is used. This is likelygoing to make accessing stack maps slightly slower, but if that's anissue we can tweak the representation and align things and/or use`usize` or such.* Update crates/environ/src/compile/stack_maps.rsCo-authored-by: Andrew Brown * Review comments* More review comments* Fix MIRI test by enabling `unaligned` object feature---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

b2025ead - Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)

Mon, 19 Aug 2024 00:18:25 +0000

Switch to new "user" stack maps and use `i32` for GC refs in Wasmtime (#9082)This moves Wasmtime over from the old, regalloc-based stack maps system to thenew "user" stack maps system.Removing the old regalloc-based stack maps system is left for follow-up work. List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

b3636ff6 - Introduce the `cranelift-bitset` crate; use it for stack maps in both Cranelift and Wasmtime (#8826)

Tue, 18 Jun 2024 15:44:38 +0000

Introduce the `cranelift-bitset` crate; use it for stack maps in both Cranelift and Wasmtime (#8826)* Introduce the `cranelift-bitset` crateThe eventual goal is to deduplicate bitset types between Cranelift and Wasmtime,especially their use in stack maps.* Use the `cranelift-bitset` crate inside both Cranelift and WasmtimeMostly for stack maps, also for a variety of other random things where`cranelift_codegen::bitset::BitSet` was previously used.* Fix stack maps unit test in cranelift-codegen* Uncomment `no_std` declaration* Fix `CompountBitSet::reserve` method* Fix `CompoundBitSet::insert` method* Keep track of the max in a `CompoundBitSet`Makes a bunch of other stuff easier, and will be needed for replacing`cranelift_entity::EntitySet`'s bitset with this thing anyways.* Add missing parens* Fix a bug around insert and reserve* Implement `with_capacity` in terms of `new` and `reserve`* Rename `reserve` to `ensure_capacity` List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

c810eff8 - Migrate the `wasmtime-environ` crate to `no_std` (#8528)

Thu, 02 May 2024 23:29:55 +0000

Migrate the `wasmtime-environ` crate to `no_std` (#8528)* Migrate the `wasmtime-environ` crate to `no_std`This commit migrates the `wasmtime-environ` crate to by default beingtagged with `#![no_std]`. Only the `component-model` and `gc` featuresare able to be built without `std`, all other features will implicitlyactivate the `std` feature as they currently require it one way oranother. CI is updated to build `wasmtime-environ` with these twofeatures active on a no_std platform.This additionally, for the workspace, disables the `std` feature for the`target-lexicon`, `indexmap`, `object`, and `gimli` dependencies. Forobject/gimli all other crates in the workspace now enable the `std`feature, but for `wasmtime-environ` this activation is omitted.The `thiserror` dependency was dropped from `wasmtime-environ` andadditionally `hashbrown` was added for explicit usage of maps.* Always enable `std` for environ for nowprtest:full* Add some more std features List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

9ec02f9d - Decouple `serde` from its `derive` crate (#6917)

Tue, 29 Aug 2023 16:02:06 +0000

Decouple `serde` from its `derive` crate (#6917)By not activating the `derive` feature on `serde`, the compilation speedcan be improved by a lot. This is because `serde` can then compile inparallel to `serde_derive`, allowing it to finish compilation possiblyeven before `serde_derive`, unblocking all the crates waiting for`serde` to start compiling much sooner.As it turns out the main deciding factor for how long the compile time of aproject is, is primarly determined by the depth of dependencies ratherthan the width. In other words, a crate's compile times aren't affectedby how many crates it depends on, but rather by the longest chain ofdependencies that it needs to wait on. In many cases `serde` is part ofthat long chain, as it is part of a long chain if the `derive` featureis active:`proc-macro2` compile build script > `proc-macro2` run build script >`proc-macro2` > `quote` > `syn` > `serde_derive` > `serde` >`serde_json` (or any crate that depends on serde)By decoupling it from `serde_derive`, the chain is shortened and compiletimes get much better.Check this issue for a deeper elaboration:https://github.com/serde-rs/serde/issues/2584For `wasmtime` I'm seeing a reduction from 24.75s to 22.45s whencompiling in `release` mode. This is because wasmtime through `gimli`has a dependency on `indexmap` which can only start compiling when`serde` is finished, which you want to happen as early as possible sosome of wasmtime's dependencies can start compiling.To measure the full effect, the dependencies can't by themselvesactivate the `derive` feature. I've upstreamed a patch for`fxprof-processed-profile` which was the only dependency that activatedit for `wasmtime` (not yet published to crates.io). `wasmtime-cli` andco. may need patches for their dependencies to see a similarimprovement. List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

453feb6f - Remove some dead code (#3970)

Wed, 30 Mar 2022 18:51:34 +0000

Remove some dead code (#3970)This commit removes methods that are never used between crates or trait impls like `Clone` which may have been used one day but are no longer used. List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs

87c33c29 - Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199)

Wed, 18 Aug 2021 18:14:52 +0000

Remove `wasmtime-environ`'s dependency on `cranelift-codegen` (#3199)* Move `CompiledFunction` into wasmtime-cranelift This commit moves the `wasmtime_environ::CompiledFunction` type into the `wasmtime-cranelift` crate. This type has lots of Cranelift-specific pieces of compilation and doesn't need to be generated by all Wasmtime compilers. This replaces the usage in the `Compiler` trait with a `Box` type that each compiler can select. Each compiler must still produce a `FunctionInfo`, however, which is shared information we'll deserialize for each module. The `wasmtime-debug` crate is also folded into the `wasmtime-cranelift` crate as a result of this commit. One possibility was to move the `CompiledFunction` commit into its own crate and have `wasmtime-debug` depend on that, but since `wasmtime-debug` is Cranelift-specific at this time it didn't seem like it was too too necessary to keep it separate. If `wasmtime-debug` supports other backends in the future we can recreate a new crate, perhaps with it refactored to not depend on Cranelift. * Move wasmtime_environ::reference_type This now belongs in wasmtime-cranelift and nowhere else * Remove `Type` reexport in wasmtime-environ One less dependency on `cranelift-codegen`! * Remove `types` reexport from `wasmtime-environ` Less cranelift! * Remove `SourceLoc` from wasmtime-environ Change the `srcloc`, `start_srcloc`, and `end_srcloc` fields to a custom `FilePos` type instead of `ir::SourceLoc`. These are only used in a few places so there's not much to lose from an extra abstraction for these leaf use cases outside of cranelift. * Remove wasmtime-environ's dep on cranelift's `StackMap` This commit "clones" the `StackMap` data structure in to `wasmtime-environ` to have an independent representation that that chosen by Cranelift. This allows Wasmtime to decouple this runtime dependency of stack map information and let the two evolve independently, if necessary. An alternative would be to refactor cranelift's implementation into a separate crate and have wasmtime depend on that but it seemed a bit like overkill to do so and easier to clone just a few lines for this. * Define code offsets in wasmtime-environ with `u32` Don't use Cranelift's `binemit::CodeOffset` alias to define this field type since the `wasmtime-environ` crate will be losing the `cranelift-codegen` dependency soon. * Commit to using `cranelift-entity` in Wasmtime This commit removes the reexport of `cranelift-entity` from the `wasmtime-environ` crate and instead directly depends on the `cranelift-entity` crate in all referencing crates. The original reason for the reexport was to make cranelift version bumps easier since it's less versions to change, but nowadays we have a script to do that. Otherwise this encourages crates to use whatever they want from `cranelift-entity` since we'll always depend on the whole crate. It's expected that the `cranelift-entity` crate will continue to be a lean crate in dependencies and suitable for use at both runtime and compile time. Consequently there's no need to avoid its usage in Wasmtime at runtime, since "remove Cranelift at compile time" is primarily about the `cranelift-codegen` crate. * Remove most uses of `cranelift-codegen` in `wasmtime-environ` There's only one final use remaining, which is the reexport of `TrapCode`, which will get handled later. * Limit the glob-reexport of `cranelift_wasm` This commit removes the glob reexport of `cranelift-wasm` from the `wasmtime-environ` crate. This is intended to explicitly define what we're reexporting and is a transitionary step to curtail the amount of dependencies taken on `cranelift-wasm` throughout the codebase. For example some functions used by debuginfo mapping are better imported directly from the crate since they're Cranelift-specific. Note that this is intended to be a temporary state affairs, soon this reexport will be gone entirely. Additionally this commit reduces imports from `cranelift_wasm` and also primarily imports from `crate::wasm` within `wasmtime-environ` to get a better sense of what's imported from where and what will need to be shared. * Extract types from cranelift-wasm to cranelift-wasm-types This commit creates a new crate called `cranelift-wasm-types` and extracts type definitions from the `cranelift-wasm` crate into this new crate. The purpose of this crate is to be a shared definition of wasm types that can be shared both by compilers (like Cranelift) as well as wasm runtimes (e.g. Wasmtime). This new `cranelift-wasm-types` crate doesn't depend on `cranelift-codegen` and is the final step in severing the unconditional dependency from Wasmtime to `cranelift-codegen`. The final refactoring in this commit is to then reexport this crate from `wasmtime-environ`, delete the `cranelift-codegen` dependency, and then update all `use` paths to point to these new types. The main change of substance here is that the `TrapCode` enum is mirrored from Cranelift into this `cranelift-wasm-types` crate. While this unfortunately results in three definitions (one more which is non-exhaustive in Wasmtime itself) it's hopefully not too onerous and ideally something we can patch up in the future. * Get lightbeam compiling * Remove unnecessary dependency * Fix compile with uffd * Update publish script * Fix more uffd tests * Rename cranelift-wasm-types to wasmtime-types This reflects the purpose a bit more where it's types specifically intended for Wasmtime and its support. * Fix publish script List of files: /wasmtime-44.0.1/crates/environ/src/stack_map.rs