<?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 code_builder.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>ff33e949 - Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#ff33e949</link>
        <description>Do not re-export `anyhow!` in the `wasmtime::prelude` (#12298)We are trying to move to `format_err!` instead.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Fri, 09 Jan 2026 19:23:56 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>9bb96d51 - Add `Config::without_compiler` (#12089)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#9bb96d51</link>
        <description>Add `Config::without_compiler` (#12089)* Add `Config::without_compiler`This provides us an allocation-free path for constructing a `Config`.Why not rely on builds when `cfg(not(any(feature = &quot;cranelift&quot;, feature =&quot;winch&quot;)))`? Because we need to test our various OOM-handling andallocation-free code paths in this workspace, and without some way to create aconfig without a compiler otherwise, cargo&apos;s feature resolver will enable thosefeatures in the workspace, enabling the compiler in the config, but we don&apos;tintend to make compiler configurations handle OOM.* Quiet unused mut warnings* Move default compiler flags into builder

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Tue, 02 Dec 2025 23:50:13 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>e069bdd3 - `CodeBuilder` APIs for defining compile-time builtins (#11918)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#e069bdd3</link>
        <description>`CodeBuilder` APIs for defining compile-time builtins (#11918)* `CodeBuilder` APIs for defining compile-time builtinsCompile-time builtins, as described in [theRFC](https://github.com/bytecodealliance/rfcs/blob/main/accepted/wasmtime-compile-time-builtins.md),are effectively the sum of three parts:1. Function inlining2. Unsafe intrinsics3. Component compositionThe first two have already been implemented in Wasmtime. This commit implementsthe final part, leveraging `wasm-compose` to link host-defined compile-timebuiltin components with guest-defined main components. It exposes Wasmtime&apos;sunsafe intrinsics only to the host-defined compile-time builtins, not theguest-defined main Wasm component.Why `wasm-compose` and not `wac`? Because it is in the same repo as the rest ofthe `wasm-tools` crates, and therefore it is easy to depend on without bringingin duplicate copies of that family of crates into our workspace and builds. Alsoits programmatic API is somewhat easier to use, and is not spread acrossmultiple crates.* Fix unused lifetime in `cfg(not(feature = &quot;compile-time-builtins&quot;))`* Fix an unused warning when `cfg(not(feature = &quot;compile-time-builtins&quot;))`* Add cargo vet audit for `fixedbitset` version `0.4.2`* Add cargo vet audit for `bitmaps` version 2.10.0* Add cargo vet audit for `sized-chunks` diff `0.6.5 -&gt; 0.7.0`* Add/tweak cargo vet exemptions for some depsThese all have &gt;10,000 daily downloads, and so are okay to exempt per ourpolicy:https://docs.wasmtime.dev/contributing-coding-guidelines.html#policy-for-adding-cargo-vet-entries* Add cargo vet audit for `wasm-compose` diff `0.236.0 -&gt; 0.238.1`Don&apos;t know why I have to do this certification even though we have a wildcardaudit for this crate because it is authored by the Bytecode Alliance...* Fix visibility of type* Move compile-time builtins methods to module to cut down on `cfg`s* Skip checking `heck` in `cargo deny`Until https://github.com/bytecodealliance/wasm-tools/pull/2359 is merged,released, and updated in this tree.* Always read compile-time inputs* Tighten up parse loop and level tracking* as_deref instead of clone* Remove &apos;b lifetime from CodeBuilder* fix `cfg(not(feature = &quot;compile-time-builtins&quot;))` build* Ignore tests that run wasm when in MIRI

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Thu, 23 Oct 2025 18:46:59 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>ad56ff98 - Implement unsafe intrinsics for compile-time builtins (#11825)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#ad56ff98</link>
        <description>Implement unsafe intrinsics for compile-time builtins (#11825)* Implement unsafe intrinsics for compile-time builtinsThis commit adds the extremely unsafe`wasmtime::CodeBuilder::expose_unsafe_intrinsics` method. When enabled, the Wasmbeing compiled is given access to special imports that correspond to direct,unchecked and unsandboxed, native load and store operations. These intrinsicsare intended to be used for implementing fast, inline-able versions of WASIinterfaces that are special-cased to a particular host embedding, for example.Compile-time builtins, as originally described in [theRFC](https://github.com/bytecodealliance/rfcs/pull/43), are basically made up ofthree parts:1. A function inliner2. Unsafe intrinsics3. Component composition to encapsulate the usage of unsafe intrinsics in a safeinterfacePart (1) has been implemented in Wasmtime and Cranelift for a little whilenow (see `wasmtime::Config::compiler_inlining`). This commit is part (2). Afterthis commit lands, part (3) can be done with `wac` and `wasm-compose`, althoughfollow up work is required to make the developer experience nicer and moreintegrated into Wasmtime so that the APIs can look like those proposed in theRFC.* fill out some more docs* fix non component model builds* start filling out the doc example* Factor abi params/returns out; truncate/extend pointers* Compile unsafe intrinsics on winch as well* prtest:full* have the macro define the signature* ignore tests in MIRI because MIRI can&apos;t compile Wasm* juggle pointer provenance in `Store::data[_mut]`* add a test for store data provenance and also fix it* use `VmPtr` for the store data pointer* finish writing unsafe intrinsics example* fix up docs and rules around only accessing data from `T` in a `Store&lt;T&gt;`* Only reserve space for the intrinsics&apos; `VMFuncRef`s if they are in use* use dangling pointers instead of options* Rename `StoreInner::data` to `data_no_provenance` and fix some accesses to use the method accessors* Add comments about the provenance juggling inside `StoreInner::data[_mut]`* only compile intrinsics that are usedTurns out we don&apos;t need to add phases, we already have the info available to dothis.* fix duplicate symbol names

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Fri, 17 Oct 2025 00:01:54 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.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/wasmtime/src/compile/code_builder.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/wasmtime/src/compile/code_builder.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>5eee6313 - Wasmtime: support a notion of &quot;custom code publisher&quot;. (#9778)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#5eee6313</link>
        <description>Wasmtime: support a notion of &quot;custom code publisher&quot;. (#9778)* Wasmtime: support a notion of &quot;custom code publisher&quot;.In some `no_std` environments, virtual memory usage is *generally*prohibited for performance-predictability reasons, but the MMUhardware is still in use for permissions (e.g., `W^X`write-xor-execute). Occasional changes to page mapping permissions arethus necessary when new modules are loaded dynamically, and areacceptable in that context. Wasmtime needs a way to support&quot;publishing&quot; code (making it executable) in such environments.Rather than try to segment the `signals-based-traps` divide further,and piece out the code-publishing parts from the heap parts, andbackdoor a path to `mprotect` in an otherwise `no_std` build, in thisPR I have opted to add a trait an impl of which the embedder canprovide to the `Config` to implement custom actions for &quot;codepublish&quot;. This otherwise operates properly in ano-`signals-based-traps` environment, e.g., the module backing memoryitself is regularly allocated rather than mmap&apos;d (but is now alignedto the degree requested by the trait impl).* Review feedback.* Plumb through custom alignment for runtime code generation* Add a test for custom code memory.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Tue, 10 Dec 2024 23:56:25 +0000</pubDate>
        <dc:creator>Chris Fallin &lt;chris@cfallin.org&gt;</dc:creator>
    </item>
<item>
        <title>62e51da5 - Update handling of wasm features and `*.wast` testing (#9158)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#62e51da5</link>
        <description>Update handling of wasm features and `*.wast` testing (#9158)* Update handling of wasm features and `*.wast` testingThis commit is an attempt at making it easier to manage the set ofvariables we have in play with `*.wast` testing and wasm features.The Cranelift and Winch backends support different sets of wasm featuresat this time and historically Cranelift has also hadarchitecture-specific support for wasm features. This is hoped to helpsimplify management of all of this in the future in addition to making`*.wast` testing more robust. Notable changes here are:* A `Config` no longer tracks a `WasmFeatures` but instead only tracks  explicitly disabled/enabled features. The final `WasmFeatures` is then  computed given the result of compiler configuration.* Default-enabled features now start from nothing instead of  `wasmparser`&apos;s defaults to avoid future breakage there.* Each compiler configuration and/or backend now has a listed set of  &quot;this feature may panic&quot; wasm features. These are all disabled by  default and if explicitly enabled a `Config::validate` error is  returned.* All `*.wast` tests are now run through both Cranelift and Winch. Tests  are now asserted to either fail or pass depending on configuration and  the whole test will fail if the result doesn&apos;t match the expectation.* Many `gc` proposal tests which are now passing are flagged as passing  now. Failing `winch` tests are now explicitly listed instead of using  a litany of patterns.* Change panicking features for winch* Fix builds without a compiler

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Thu, 22 Aug 2024 15:01:36 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>f673cde3 - Refactor use of `CodeBuilder` on the CLI (#9125)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#f673cde3</link>
        <description>Refactor use of `CodeBuilder` on the CLI (#9125)* Refactor use of `CodeBuilder` on the CLIThis commit refactors `wasmtime run` and `wasmtime compile` tounconditionally use `CodeBuilder` internally. This will in theory helpout in the future if more debug-related options are added to`CodeBuilder` for example. This refactoring required some changes to`CodeBuilder` to be able to support a query about whether the internalbytes were a component or a module. The text format is now converted tobinary immediately when supplied rather than during the compilationphase. This in turn required some API changes to make the selection ofsupporting the text format a compile-time choice of method rather than aruntime value.* Fix compile* Fix no-cranelift build of CLI

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Wed, 14 Aug 2024 17:31:07 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#1512a954</link>
        <description>Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe 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-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc`

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Fri, 14 Jun 2024 15:24:12 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
<item>
        <title>81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#81a89169</link>
        <description>Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime&apos;s platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren&apos;t implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime&apos;s TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the &quot;custom&quot; platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can&apos;t be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely 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&apos;t enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime&apos;s `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest: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

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Sat, 04 May 2024 22:02:26 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>964f8986 - Use rustdoc&apos;s `doc_auto_cfg` feature instead of `doc_cfg` (#8532)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#964f8986</link>
        <description>Use rustdoc&apos;s `doc_auto_cfg` feature instead of `doc_cfg` (#8532)This commit removes all our `#[cfg_attr(..., doc(cfg(...)))]`annotations throughout Wasmtime and `wasmtime-wasi`. These are allreplaced with `feature(doc_auto_cfg)` which automatically infers theattribute to show rather than requiring us to duplicate it.Spot-checking the docs this looks just-as-readable while being mucheasier to maintain over time.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Fri, 03 May 2024 16:01:12 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>fb4f4cd3 - Add initial support for DWARF Fission (#8055)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#fb4f4cd3</link>
        <description>Add initial support for DWARF Fission (#8055)* add cloning for String attributes* use into_owned instead of to_vec to avoid a clone if possible.* runs, but does not substitute* show vars from c program, start cleanup* tiday* resolve conflicts* remove WASI folder* Add module_builderadd dwarf_package to state for cache* move dwarf loading to module_environ.rspass the dwarf as binary as low as module_environ.rs* pass dwarf package rather than add to debug_info* tidy option/result nested if* revert some toml and whitespace.* add features cranelift,winch to module_builder and compute_artifactsremove some `use`s* address some feedbackremove unused &apos;use&apos;s* address some feedbackremove unused &apos;use&apos;s* move wat feature condition to cover whole method.* More feedbackAnother try at wat feature move* Another try at wat feature move* change gimli exemption versionadd typed-arena exemption* add None for c-api* move `use` to #cfg* fix another config build* revert unwanted code deletion* move inner function closer to use* revert extra param to Module::new* workaround object crate bug.* add missing parameter* add missing parameter* Merge remote-tracking branch &apos;origin/main&apos; into dwarf-att-string# Conflicts:#	crates/wasmtime/src/engine.rs#	crates/wasmtime/src/runtime/module.rs#	src/common.rs* remove moduke* use common gimli version of 28.1* remove wasm feature, revert gimli version* remove use of object for wasm dwarf* remove NativeFile workaround, add feature for dwp loading* sync winch signature* revert bench api change* add dwarf for no cache feature* put back merge loss of module kind* remove param from docs* add dwarf fission lldb test* simplify and include test source* clang-format* address feedback, remove packagesadd docssimplify return type* remove Default use on ModuleTypesBuilder* Remove an `unwrap()` and use `if let` instead* Use `&amp;[u8]` instead of `&amp;Vec&lt;u8&gt;`* Remove an `unwrap()` and return `None` instead* Clean up some code in `transform_dwarf`* Clean up some code in `replace_unit_from_split_dwarf`* Clean up some code in `split_unit`* Minor refactorings and documentation in `CodeBuilder`* Restrict visibility of `dwarf_package_binary`* Revert supply-chain folder changes* Fix compile error on nightly* prtest:full* prtest:full* prtest:full* prtest:full* prtest:full* prtest:full* prtest:full* prtest:full* use lldb 15* prtest:full* prtest:full* load dwp when loading wasm bytes with path* correct source file name* remove debug---------Co-authored-by: Alex Crichton &lt;alex@alexcrichton.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Wed, 24 Apr 2024 14:23:08 +0000</pubDate>
        <dc:creator>yowl &lt;scott.waye@hubse.com&gt;</dc:creator>
    </item>
<item>
        <title>d38d387a - Fix rustdoc warnings on Nightly (#8258)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#d38d387a</link>
        <description>Fix rustdoc warnings on Nightly (#8258)* Fix rustdoc warnings on NightlyI noticed during a failed doc build of another PR we&apos;ve got a number ofwarnings being emitted, so resolve all those here.* Fix more warnings* Fix rebase conflicts

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Thu, 28 Mar 2024 19:19:22 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>1a7de7cc - Add a `compile` feature to `wasmtime-environ` (#8250)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#1a7de7cc</link>
        <description>Add a `compile` feature to `wasmtime-environ` (#8250)* Add a `compile` feature to `wasmtime-environ`This commit adds a compile-time feature to remove some dependencies ofthe `wasmtime-environ` crate. This compiles out support for compilingmodules/components and makes the crate slimmer in terms of amount ofcode compiled along with its dependencies. Much of this should alreadyhave been statically removed by native linkers so this likely won&apos;t haveany compile-size impact, but it&apos;s a nice-to-have in terms oforganization.This has a fair bit of shuffling around of code, but apart fromrenamings and movement there are no major changes here.* Fix compile issue* Gate `ModuleTranslation` and its methods on `compile`* Fix doc link* Fix doc link

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Thu, 28 Mar 2024 16:07:12 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>b0be4a88 - Fix compilation cache for components (#8251)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#b0be4a88</link>
        <description>Fix compilation cache for components (#8251)This commit fixes a mistake in #8181 which meant that the caching forcomponents was no longer working. The mistake is fixed in this commit aswell as a new test being added too.

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Thu, 28 Mar 2024 05:38:20 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>55664f5a - Add a `CodeBuilder` type to the `wasmtime` crate (#8181)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs#55664f5a</link>
        <description>Add a `CodeBuilder` type to the `wasmtime` crate (#8181)* Add a `ModuleBuilder` type to the `wasmtime` crateThis commit is extracted from #8055 and adds a new `ModuleBuilder` typewhich is intended to be able to further configure compilation beyondwhat the constructors of `Module` already provide. For example in #8055knobs will be added to process `*.dwp` files for more debuginfoprocessing.Co-authored-by: yowl00 &lt;scott.waye@hubse.com&gt;* Fix build* Review feedback* Rename ModuleBuilder to CodeBuilder* Fix doc errors---------Co-authored-by: yowl00 &lt;scott.waye@hubse.com&gt;

            List of files:
            /wasmtime-44.0.1/crates/wasmtime/src/compile/code_builder.rs</description>
        <pubDate>Wed, 20 Mar 2024 20:52:14 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
</channel>
</rss>
