<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in address_transform.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>cfc05638 - Make Wasmtime&apos;s `FuncKey` one-to-one with Cranelift&apos;s `ir::UserExternalName` (#11415)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#cfc05638</link>
        <description>Make Wasmtime&apos;s `FuncKey` one-to-one with Cranelift&apos;s `ir::UserExternalName` (#11415)* Make Wasmtime&apos;s `FuncKey` one-to-one with Cranelift&apos;s `ir::UserExternalName``FuncKey`, which used to be called `CompileKey`, is now one-to-one with`cranelift_codegen::ir::UserExternalName`, and is used for not just identifyingcompilation objects but also relocations and call-graph edges. This allows us todetermine the `StaticModuleIndex` and `DefinedFuncIndex` pair for any`cranelift_codegen::ir::FuncRef`, regardless of inlining depth, which fixes somefuzz bugs on OSS-Fuzz.This continues pushing on the idea that Wasmtime&apos;s compilation orchestration andlinking should be relatively agnostic to the kinds of things it is actuallycompiling and linking, allowing us to tweak, add, and remove new kinds of`FuncKey`s more easily. Adding a new `FuncKey` should not require modifyingrelocation resolution, for example, just a little bit of code to run theassociated compilation and optionally some code to extract metadata into ourfinal artifacts for querying at runtime. Everything in between should JustContinue Working. We still aren&apos;t all the way there yet, but this does bring usa little bit closer.Finally, in Cranelift&apos;s inlining pass, this adds a check that a block isinserted in the layout before attempting to remove it from the layout, whichwould otherwise cause panics. This was triggered by multi-level inlining andnow-unreachable blocks in the inner callees.I&apos;ll note that this does update basically all of the disas tests, or at leastnearly all of them that make function calls. This is because the namespace/indexnumbering pair changed slightly to align with `FuncKey`, but that should prettymuch be the only changes.* remove debug info from panic message, it is only available in some `cfg`s* fill out module doc comment* Fix compilation without `component-model` feature* Fix some more cfg compilations* cargo fmt* fix a wrong `&amp;dyn Any` auto coercion; add helpful debug logging and assertions for this kind of thing

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Tue, 12 Aug 2025 18:38:04 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9b0e1b9d - Improve garbage collection of DWARF for dead code (#11402)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#9b0e1b9d</link>
        <description>Improve garbage collection of DWARF for dead code (#11402)Checking for the tombstone address during the reachability calculationallows more DWARF entries to be marked as unreachable, and there wasalready code to handle this for addresses left as 0.

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Fri, 08 Aug 2025 15:36:39 +0000</pubDate>
        <dc:creator>Philip Craig &lt;philipjcraig@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>703871a2 - Enable the `useless_conversion` Clippy lint (#10838)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#703871a2</link>
        <description>Enable the `useless_conversion` Clippy lint (#10838)* Enable the `useless_conversion` Clippy lintWe&apos;ve got lots of types in Wasmtime and convert between them quite alot, but often over time conversions become unnecessary throughrefactorings or similar. This will hopefully enable us to clean up someconversions as they come up to try to have as few as possible ideally.* Review comments

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Tue, 27 May 2025 16:49:22 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#90ac295e</link>
        <description>Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it&apos;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/transform/address_transform.rs</description>
        <pubDate>Mon, 19 May 2025 16:40:55 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>48f4621f - Run the full test suite on 32-bit platforms (#9837)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#48f4621f</link>
        <description>Run the full test suite on 32-bit platforms (#9837)* Run the full test suite on 32-bit platformsThis commit switches to running the full test suite in its entirety(`./ci/run-tests.sh`) on 32-bit platforms in CI in addition to 64-bitplatforms. This notably adds i686 and armv7 as architectures that aretested in CI.Lots of little fixes here and there were applied to a number of tests.Many tests just don&apos;t run on 32-bit platforms or a platform withoutCranelift support, and they&apos;ve been annotated as such where necessary.Other tests were adjusted to run on all platforms a few minor bug fixesare here as well.prtest:full* Fix clippy warning* Get wasm code working by default on 32-bitDon&apos;t require the `pulley` feature opt-in on 32-bit platforms to getwasm code running.* Fix dead code warning* Fix build on armv7* Fix test assertion on armv7* Review comments* Update how tests are skipped* Change how Pulley is defaultedDefault to pulley in `build.rs` rather than in `Cargo.toml` to make iteasier to write down the condition and comment what&apos;s happening. Thismeans that the `pulley-interpreter` crate and pulley support inCranelift is always compiled in now and cannot be removed. This shouldhopefully be ok though as the `pulley-interpreter` crate is stillconditionally used (meaning it can get GC&apos;d) and the code-size ofCranelift is not as important as the runtime itself.* pulley: Save/restore callee-save state on traps* Fewer clippy warnings about casts* Use wrapping_add in `g32_addr`, fixing arm test

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Wed, 15 Jan 2025 18:43:18 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>dd8c48b3 - Add basic support for DWARF processing with components (#8693)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#dd8c48b3</link>
        <description>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&apos;ll admit I&apos;m not expert on DWARF but basic examples appear to worklocally and most of the additions here seemed relatively straightforwardin terms of &quot;add another loop to iterate over more things&quot; but I&apos;m not100% sure how well this will work. In theory this now supportsconcatenating DWARF sections across multiple core wasm modules, butthat&apos;s not super well tested.

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Wed, 05 Jun 2024 21:24:45 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>0e9121da - Fix some typos (#8641)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#0e9121da</link>
        <description>Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown &lt;andrew.brown@intel.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Thu, 16 May 2024 23:21:22 +0000</pubDate>
        <dc:creator>FrankReh &lt;FrankReh@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>b545cc50 - Remove the wasmtime-cranelift-shared crate (#8222)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#b545cc50</link>
        <description>Remove the wasmtime-cranelift-shared crate (#8222)The wasmtime-cranelift-shared crate is not as useful as it once was, asit&apos;s no longer possible to build wasmtime with only winch; winch usesthe trampolines generated by cranelift now.

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Fri, 22 Mar 2024 19:29:38 +0000</pubDate>
        <dc:creator>Trevor Elliott &lt;telliott@fastly.com&gt;</dc:creator>
    </item>
<item>
        <title>9ce3ffe1 - Update some CI dependencies (#7983)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#9ce3ffe1</link>
        <description>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 MIRIprtest: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

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Thu, 22 Feb 2024 23:54:03 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1cbca5a5 - winch: Handle relocations and traps (#6298)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#1cbca5a5</link>
        <description>winch: Handle relocations and traps (#6298)* winch: Handle relocations and trapsThis change introduces handling of traps and relocations in Winch, whichwas left out in https://github.com/bytecodealliance/wasmtime/pull/6119.In order to so, this change moves the `CompiledFunction` struct to the`wasmtime-cranelift-shared` crate, allowing Cranelift and Winch tooperate on a single, shared representation, following some of the ideasdiscussed in https://github.com/bytecodealliance/wasmtime/pull/5944.Even though Winch doesn&apos;t rely on all the fields of `CompiledFunction`,it eventually will. With the addition of relocations and traps itstarted to be more evident that even if we wanted to have differentrepresentations of a compiled function, they would end up being verysimilar.This change also consolidates where the `traps` and `relocations` of the`CompiledFunction` get created, by introducing a constructor thatoperates on a `MachBufferFinalized&lt;Final&gt;`, esentially encapsulatingthis process in a single place for both Winch and Cranelift.* Rework the shared `CompiledFunction`This commit reworks the shared `CompiledFunction` struct. The compiledfunction now contains the essential pieces to derive all the informationto create the final object file and to derive the debug information forthe function.This commit also decouples the dwarf emission process by introducinga `metadata` field in the `CompiledFunction` struct, which is used asthe central structure for dwarf emission.

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Tue, 02 May 2023 19:48:56 +0000</pubDate>
        <dc:creator>Sa&#250;l Cabrera &lt;saulecabrera@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>cd53bed8 - Implement AOT compilation for components (#5160)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#cd53bed8</link>
        <description>Implement AOT compilation for components (#5160)* Pull `Module` out of `ModuleTextBuilder`This commit is the first in what will likely be a number towardspreparing for serializing a compiled component to bytes, a precompiledartifact. To that end my rough plan is to merge all of the compiledartifacts for a component into one large object file instead of havinglots of separate object files and lots of separate mmaps to manage. Tothat end I plan on eventually using `ModuleTextBuilder` to build onelarge text section for all core wasm modules and trampolines, meaningthat `ModuleTextBuilder` is no longer specific to one module. I&apos;veextracted out functionality such as function name calculation as well asrelocation resolving (now a closure passed in) in preparation for this.For now this just keeps tests passing, and the trajectory for thisshould become more clear over the following commits.* Remove component-specific object emissionThis commit removes the `ComponentCompiler::emit_obj` function in favorof `Compiler::emit_obj`, now renamed `append_code`. This involvedsignificantly refactoring code emission to take a flat list of functionsinto `append_code` and the caller is responsible for weaving togethervarious &quot;families&quot; of functions and un-weaving them afterwards.* Consolidate ELF parsing in `CodeMemory`This commit moves the ELF file parsing and section iteration from`CompiledModule` into `CodeMemory` so one location keeps track ofsection ranges and such. This is in preparation for sharing much of thiscode with components which needs all the same sections to get trackedbut won&apos;t be using `CompiledModule`. A small side benefit from this isthat the section parsing done in `CodeMemory` and `CompiledModule` is nolonger duplicated.* Remove separately tracked traps in componentsPreviously components would generate an &quot;always trapping&quot; functionand the metadata around which pc was allowed to trap was handledmanually for components. With recent refactorings the Wasmtime-standardtrap section in object files is now being generated for components aswell which means that can be reused instead of custom-tracking thismetadata. This commit removes the manual tracking for the `always_trap`functions and plumbs the necessary bits around to make components lookmore like modules.* Remove a now-unnecessary `Arc` in `Module`Not expected to have any measurable impact on performance, butcomplexity-wise this should make it a bit easier to understand theinternals since there&apos;s no longer any need to store this somewhere elsethan its owner&apos;s location.* Merge compilation artifacts of componentsThis commit is a large refactoring of the component compilation processto produce a single artifact instead of multiple binary artifacts. Thecore wasm compilation process is refactored as well to share as muchcode as necessary with the component compilation process.This method of representing a compiled component necessitated a fewmedium-sized changes internally within Wasmtime:* A new data structure was created, `CodeObject`, which represents  metadata about a single compiled artifact. This is then stored as an  `Arc` within a component and a module. For `Module` this is always  uniquely owned and represents a shuffling around of data from one  owner to another. For a `Component`, however, this is shared amongst  all loaded modules and the top-level component.* The &quot;module registry&quot; which is used for symbolicating backtraces and  for trap information has been updated to account for a single region  of loaded code holding possibly multiple modules. This involved adding  a second-level `BTreeMap` for now. This will likely slow down  instantiation slightly but if it poses an issue in the future this  should be able to be represented with a more clever data structure.This commit additionally solves a number of longstanding issues withcomponents such as compiling only one host-to-wasm trampoline persignature instead of possibly once-per-module. Additionally the`SignatureCollection` registration now happens once-per-componentinstead of once-per-module-within-a-component.* Fix compile errors from prior commits* Support AOT-compiling componentsThis commit adds support for AOT-compiled components in the same manneras `Module`, specifically adding:* `Engine::precompile_component`* `Component::serialize`* `Component::deserialize`* `Component::deserialize_file`Internally the support for components looks quite similar to `Module`.All the prior commits to this made adding the support here(unsurprisingly) easy. Components are represented as a single objectfile as are modules, and the functions for each module are all piledinto the same object file next to each other (as are areas such as datasections). Support was also added here to quickly differentiate compiledcomponents vs compiled modules via the `e_flags` field in the ELFheader.* Prevent serializing exported modules on componentsThe current representation of a module within a component means that theimplementation of `Module::serialize` will not work if the module isexported from a component. The reason for this is that `serialize`doesn&apos;t actually do anything and simply returns the underlying mmap as alist of bytes. The mmap, however, has `.wasmtime.info` describingcomponent metadata as opposed to this module&apos;s metadata. While rewritingthis section could be implemented it&apos;s not so easy to do so and isotherwise seen as not super important of a feature right now anyway.* Fix windows build* Fix an unused function warning* Update crates/environ/src/compilation.rsCo-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;Co-authored-by: Nick Fitzgerald &lt;fitzgen@gmail.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Wed, 02 Nov 2022 15:26:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1321c234 - Remove dependency on `more-asserts` (#4408)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#1321c234</link>
        <description>Remove dependency on `more-asserts` (#4408)* Remove dependency on `more-asserts`In my recent adventures to do a bit of gardening on our dependencies Inoticed that there&apos;s a new major version for the `more-asserts` crate.Instead of updating to this though I&apos;ve opted to instead remove thedependency since I don&apos;t think we heavily lean on this crate andotherwise one-off prints are probably sufficient to avoid the need forpulling in a whole crate for this.* Remove exemption for `more-asserts`

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Tue, 26 Jul 2022 16:47:33 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>fc911766 - Move address maps to a section of the compiled image (#3240)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#fc911766</link>
        <description>Move address maps to a section of the compiled image (#3240)This commit moves the `address_map` field of `FunctionInfo` into acustom-encoded section of the executable. The goal of this commit is, asprevious commits, to push less data through `bincode`. The `address_map`field is actually extremely large and has huge benefits of not beingdecoded when we load a module. This data is only used for traps and suchas well, so it&apos;s not overly important that it&apos;s massaged in to precisedata the runtime can extremely speedily use.The `FunctionInfo` type does retain a tiny bit of information about thefunction itself (it&apos;s start source location), but other than that the`FunctionAddressMap` structure is moved from `wasmtime-environ` to`wasmtime-cranelift` since it&apos;s now no longer needed outside of thatcontext.

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Fri, 27 Aug 2021 04:06:41 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>6fbddc19 - Replace some cfg(debug) with cfg(debug_assertions) (#3242)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#6fbddc19</link>
        <description>Replace some cfg(debug) with cfg(debug_assertions) (#3242)* Replace some cfg(debug) with cfg(debug_assertions)Cargo nor rustc ever sets `cfg(debug)` automatically, so it&apos;s expectedthat these usages were intended to be `cfg(debug_assertions)`.* Fix MachBuffer debug-assertion invariant checks.We should only check invariants when we expect them to be true --specifically, before the branch-simplification algorithm runs. At othertimes, they may be temporarily violated: e.g., after`add_{cond,uncond}_branch()` but before emitting the branch bytes. Thisis the expected sequence, and the rest of the code is consistent withthat.Some of the checks also were not quite right (w.r.t. the writteninvariants); specifically, we should not check validity of a label&apos;soffset when the label has been aliased to another label.It seems that this is an unfortunate consequence of leftoverdebug-assertions that weren&apos;t actually being run, so weren&apos;t keptup-to-date. Should no longer happen now that we actually check these!Co-authored-by: Chris Fallin &lt;chris@cfallin.org&gt;

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Thu, 26 Aug 2021 03:15:24 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>87c33c29 - Remove `wasmtime-environ`&apos;s dependency on `cranelift-codegen` (#3199)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs#87c33c29</link>
        <description>Remove `wasmtime-environ`&apos;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&apos;t need to be generated by all Wasmtimecompilers. This replaces the usage in the `Compiler` trait with a`Box&lt;Any&gt;` type that each compiler can select. Each compiler must stillproduce a `FunctionInfo`, however, which is shared information we&apos;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&apos;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&apos;s not much to lose from an extra abstraction for theseleaf use cases outside of cranelift.* Remove wasmtime-environ&apos;s dep on cranelift&apos;s `StackMap`This commit &quot;clones&quot; 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&apos;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&apos;t use Cranelift&apos;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&apos;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&apos;ll always depend on the whole crate.It&apos;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&apos;s no need to avoid its usage inWasmtime at runtime, since &quot;remove Cranelift at compile time&quot; isprimarily about the `cranelift-codegen` crate.* Remove most uses of `cranelift-codegen` in `wasmtime-environ`There&apos;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&apos;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&apos;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&apos;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&apos;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&apos;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&apos;s types specificallyintended for Wasmtime and its support.* Fix publish script

            List of files:
            /wasmtime-44.0.1/crates/cranelift/src/debug/transform/address_transform.rs</description>
        <pubDate>Wed, 18 Aug 2021 18:14:52 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
