Changes in debug.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

de1ad347 - Enable `impl-trait-overcaptures` 2024 transition lint (#9965)

Thu, 09 Jan 2025 23:13:22 +0000

Enable `impl-trait-overcaptures` 2024 transition lint (#9965)* Enable `impl-trait-overcaptures` 2024 transition lintThis lint detects cases where returning `impl Trait` will workdifferently in 2024 than in the current 2021 edition. Ambiguities areresolved with `use<..>` syntax stabilized in Rust 1.82.0 to mean thesame thing in both editions.* Fix some more `impl Trait` returns* Tighten bounds on settings `iter`* Fix build on 1.82.0* Fix another capture on MSRV List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

45b60bd6 - Start using `#[expect]` instead of `#[allow]` (#9696)

Mon, 02 Dec 2024 17:19:20 +0000

Start using `#[expect]` instead of `#[allow]` (#9696)* Start using `#[expect]` instead of `#[allow]`In Rust 1.81, our new MSRV, a new feature was added to Rust to use`#[expect]` to control lint levels. This new lint annotation willsilence a lint but will itself cause a lint if it doesn't actuallysilence anything. This is quite useful to ensure that annotations don'tget stale over time.Another feature is the ability to use a `reason` directive on theattribute with a string explaining why the attribute is there. Thisstring is then rendered in compiler messages if a warning or errorhappens.This commit migrates applies a few changes across the workspace:* Some `#[allow]` are changed to `#[expect]` with a `reason`.* Some `#[allow]` have a `reason` added if the lint conditionally fires (mostly related to macros).* Some `#[allow]` are removed since the lint doesn't actually fire.* The workspace configures `clippy::allow_attributes_without_reason = 'warn'` as a "ratchet" to prevent future regressions.* Many crates are annotated to allow `allow_attributes_without_reason` during this transitionary period.The end-state is that all crates should use`#[expect(..., reason = "...")]` for any lint that unconditionally firesbut is expected. The `#[allow(..., reason = "...")]` lint should be usedfor conditionally firing lints, primarily in macro-related code.The `allow_attributes_without_reason = 'warn'` level is intended to bepermanent but the transitionary`#[expect(clippy::allow_attributes_without_reason)]` crate annotationsto go away over time.* Fix adapter buildprtest:full* Fix one-core build of icache coherence* Use `allow` for missing_docsWork around rust-lang/rust#130021 which was fixed in Rust 1.83 and isn'tfixed for our MSRV at this time.* More MSRV compat List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

92cc0ad7 - Add very basic logging to the debug info transform (#9526)

Mon, 04 Nov 2024 21:15:43 +0000

Add very basic logging to the debug info transform (#9526)* Add very basic logging to the debug info transformThe DI transform is a kind of compiler and loggingis a very good way to gain insight into compilers.* Fix C&P* Bubble the "trace-log" feature up the dependency treeAnd switch logging macros to always be enabled in debug.Verified "trace-log" **does not** show up when running'cargo tree -f "{p} {f}" -e features,normal,build'* Fix dead code warnings List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

7be834f6 - Enable some Clippy conversion lints for `wasmtime-cranelift` (#9536)

Fri, 01 Nov 2024 17:20:04 +0000

Enable some Clippy conversion lints for `wasmtime-cranelift` (#9536)Similar to how `wasmtime::runtime` has a few off-by-default lints turnedon for it do the same for the compilation phase of `wasmtime-cranelift`.This is intended to help weed out lossy `as` casts and instead steerusers to `from` or `try_from` conversions. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

cdb59304 - Handle defined shared memories in dwarf processing (#8750)

Thu, 06 Jun 2024 13:26:15 +0000

Handle defined shared memories in dwarf processing (#8750)This commit resolves an assert in the dwarf generating of core wasmmodules when the module has a defined linear memory which is flagged`shared`. This is represented slightly differently in the `VMContext`than owned memories that aren't `shared`, and looks more like animported memory. With support in #8740 it's now much easier to supportthis.Closes #8652 List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

dd8c48b3 - Add basic support for DWARF processing with components (#8693)

Wed, 05 Jun 2024 21:24:45 +0000

Add basic support for DWARF processing with components (#8693)This commit updates the native-DWARF processing (the `-D debug-info` CLIflag) to support components. Previously component support was notimplemented and if there was more than one core wasm module within acomponent then dwarf would be ignored entirely.This commit contains a number of refactorings to plumb a more fullcompilation context throughout the dwarf processing pipeline. Previouslythe data structures used only were able to support a single module. Anew `Compilation` structure is used to represent the results of anentire compilation and is plumbed through the various locations. Most ofthe refactorings in this commit were then to extend loops to loop overmore things and handle the case where there is more than one core wasmmodule.I'll admit I'm not expert on DWARF but basic examples appear to worklocally and most of the additions here seemed relatively straightforwardin terms of "add another loop to iterate over more things" but I'm not100% sure how well this will work. In theory this now supportsconcatenating DWARF sections across multiple core wasm modules, butthat's not super well tested. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

fcf1054b - Add some support for imported memories to generated DWARF (#8740)

Wed, 05 Jun 2024 18:18:49 +0000

Add some support for imported memories to generated DWARF (#8740)This is more-or-less a prerequisite for #8652 and extends the generateddwarf with expressions to not only dereference owned memories butadditionally imported memories which involve some extra addresscalculations to be emitted in the dwarf. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

67adf149 - Update nightly used in CI and fix warnings (#8416)

Fri, 19 Apr 2024 20:16:47 +0000

Update nightly used in CI and fix warnings (#8416)Fixes some warnings that nightly Rust has started emitting. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

1c8fd8c5 - Cranelift: Clean up imports to avoid warnings (#7508)

Wed, 08 Nov 2023 23:07:37 +0000

Cranelift: Clean up imports to avoid warnings (#7508)Depending on which backends were enabled or not at compile time we might ormight not use some of these imports, which results in warnings. Moved importsand re-exports around a little to avoid these warnings.No functional changes. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

62fdafa1 - Remove clippy configuration from repo and crates (#6927)

Tue, 29 Aug 2023 21:07:27 +0000

Remove clippy configuration from repo and crates (#6927)Wasmtime's CI does not run clippy so there's no enforcement of thisconfiguration. Additionally the configuration per-crate is not uniformlyapplied across all of the Wasmtime workspace and is only on somehistorical crates. Because we don't run clippy in CI this commit removesall of the clippy annotations for allow/warn/deny from the source. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.rs

eb21ae14 - Move definition of ModuleMemoryOffset (#3228)

Mon, 23 Aug 2021 19:42:21 +0000

Move definition of ModuleMemoryOffset (#3228)This was historically defined in `wasmtime-environ` but it's only used in `wasmtime-cranelift`, so this commit moves the definition to the `debug` module where it's primarily used. List of files: /wasmtime-44.0.1/crates/cranelift/src/debug.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/cranelift/src/debug.rs