Changes in lib.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

76911c29 - Partial support for no_std in cranelift_codegen (#12222)

Wed, 07 Jan 2026 16:41:32 +0000

Partial support for no_std in cranelift_codegen (#12222)* Move most things from std to core and alloc* Port assembler_x64 to no_std* before adding prelude to each file* Most of the files now work with no_std* update isle to use alloc and core* some instances shouldn't have been renamed, fixes cargo test* add cranelift-assembler-x64 (no_std) to CI* fix codegen_meta, missed one spot with std::slice* automatically remove prelude with cargo fix* update isle changes* update assembler changes* update assembler changes* use latest codegen changes + fix FxHash problem* add imports* fix floating issues with libm* remove unused import* temporarily remove OnceLock* add no_std arm support and add it into CI* Move most things from std to core and alloc* Port assembler_x64 to no_std* before adding prelude to each file* Most of the files now work with no_std* update isle to use alloc and core* some instances shouldn't have been renamed, fixes cargo test* add cranelift-assembler-x64 (no_std) to CI* automatically remove prelude with cargo fix* update isle changes* update assembler changes* update assembler changes* use latest codegen changes + fix FxHash problem* add imports* fix floating issues with libm* remove unused import* temporarily remove OnceLock* add no_std arm support and add it into CI* Move most things from std to core and alloc* Port assembler_x64 to no_std* before adding prelude to each file* Most of the files now work with no_std* update isle to use alloc and core* add cranelift-assembler-x64 (no_std) to CI* automatically remove prelude with cargo fix* update isle changes* update assembler changes* use latest codegen changes + fix FxHash problem* add imports* fix floating issues with libm* temporarily remove OnceLock* add no_std arm support and add it into CI* revert Cargo.toml formating* remove prelude and fix cargo.toml* cargo fmt* remove empty lines* bad renames* macro_use only on no_std* revert OnceLock change* only use stable libm features* update regalloc2* update comment* use continue instead* Update vets---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

a3d6e407 - Cranelift: add debug tag infrastructure. (#11768)

Mon, 06 Oct 2025 19:38:03 +0000

Cranelift: add debug tag infrastructure. (#11768)* Cranelift: add debug tag infrastructure.This PR adds *debug tags*, a kind of metadata that can attach to CLIFinstructions and be lowered to VCode instructions and as metadata onthe produced compiled code. It also adds opaque descriptor blobscarried with stackslots. Together, these two features allow decoratingIR with first-class debug instrumentation that is properly preservedby the compiler, including across optimizations andinlining. (Wasmtime's use of these features will come in followupPRs.)The key idea of a "debug tag" is to allow the Cranelift embedder toexpress whatever information it needs to, in a format that is opaqueto Cranelift itself, except for the parts that need translation duringlowering. In particular, the `DebugTag::StackSlot` variant getstranslated to a physical offset into the stackframe in the compiledmetadata output. So, for example, the embedder can emit a tagreferring to a stackslot, and another describing an offset in thatstackslot.The debug tags exist as a *sequence* on any given instruction; themeaning of the sequence is known only to the embedder, *except* thatduring inlining, the tags for the inlining call instruction areprepended to the tags of inlined instructions. In this way, acanonical use-case of tags as describing original source-languageframes can preserve the source-language view even when multiplefunctions are inlined into one.The descriptor on a stackslot may look a little odd at first, but itspurpose is to allow serializing some description ofstackslot-contained runtime user-program data, in a way that is firmlyattached to the stackslot. In particular, in the face of inlining,this descriptor is copied into the inlining (parent) function from theinlined function when the stackslot entity is copied; no othermetadata outside Cranelift needs to track the identity of stackslotsand know about that motion. This fits nicely with the ability of tagsto refer to stackslots; together, the embedder can annotateinstructions as having certain state in stackslots, and describe theformat of that state per stackslot.This infrastructure is tested with some compile-tests now;testing of the interpretation of the metadata output will come withend-to-end debug instrumentation tests in a followup PR.* Review feedback: add back sequence points and enforce tags only on sequence points or calls.* Use Vecs for debug metadata in MachBuffer to avoid SmallVec size penalty in not-used case.* Review feedback: switch from inlined stackslot descriptor blobs to u64 keys. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

4f2fa154 - Update nightly Rust used in CI (#11755)

Mon, 29 Sep 2025 18:12:14 +0000

Update nightly Rust used in CI (#11755)* Update nightly Rust used in CIKeeping it up-to-dateprtest:full* Fix unused warnings on nightly* Rename rustdoc feature* Adjust some removals List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

4590076f - Cranelift: support dynamic contexts in exception-handler lists. (#11321)

Sat, 26 Jul 2025 01:35:57 +0000

Cranelift: support dynamic contexts in exception-handler lists. (#11321)In #11285, we realized that Wasm semantics require us to match ondynamic instances of exception tags, rather than static tag types. Thisfundamentally requires the unwinder to be able to resolve the currentWasm instance for each Wasm frame on the stack that has any handlers,and our frame format does not provide this today.We discussed many options, some of which solve the more general problem(Wasm vmctx for any frame), but ultimately landed on a notion of"dynamic context for evaluating tags", specific to Cranelift'sexception-catch metadata; and storing that context and carrying itthrough to a place that is named in the unwind metadata. The reasoningis fairly straightforward: we cannot afford a more general approach thatstores vmctx in every frame (I measured this at 20% overhead for arecursive-Fibonacci benchmark that is call-intensive); and inliningmeans that we may have *multiple* contexts at any given program point,each associated with a different slice of the handler tags; so we need amechanism that, *just for a try-call*, intersperses contexts with tags(or puts a context on each tag) and stores these somewhere that theexception-unwind ABI doesn't clobber (e.g., on the stack).This PR implements "option 4" from that issue, namely, *dynamicexception contexts*. The idea is that this is the dual to exceptionpayload: while payload lets the unwinder communicate state *to* thecatching code, context lets the unwinder take state *from* the catchingcode that lets it decide whether the tag is a match. Because ofinlining, we need to either associate (optional) context with every tag,or intersperse context-updates with handler tags. I've opted for thelatter for efficiency at the CLIF level (in most cases there will bemultiple tags per context), though they are isomorphic.The new tag-matching semantics are: when walking up the stack, uponreaching a `try_call`, evaluate catch-clauses in listed order. A`context` clause sets the current context. A `tagN: block(...)` clauseattempts to match the throwing exception against `tagN`, *evaluated inthe current context*, and branches to the named block if it matches. A`default: block(...)` always branches to the named block.Note that this lets us assume less about tags than before, and thisparticularly manifests in the changes to the inliner. Whereas before,`tagN` is `tagN` and an inner handler for that tag shadows an outerhandler (that is, tags always alias if identical indices); and whereasbefore, `tagN` is not `tagM` and so we can order the tags arbitrarily(that is, tags never alias if non-identical indices); now any two statictag indices may or may not alias depending on the dynamic context ofeach. Or, even in the same context, two may alias, because we leave thematch-predicate as an unspecified (user-chosen) algorithm duringunwinding. (This mirrors the reality that, for example, a Wasm instancemay import two tags, and dynamically these tags may be equal ordifferent at runtime, even instantiation-to-instantiation.) Cranelift'sonly job is to faithfully carry the list of contexts and tags through tothe compiled-code metadata; and to ensure that they remain in the orderthey were specified in the CLIF.This PR introduces the Cranelift-level feature, and it will be used ina subsequent PR that introduces Wasm exception handling. Because ofthat, I've opted not to update the clif-utils runtest "runtime" to readout contexts and do something with them -- we will have plenty of testcoverage via a bunch of Wasm tests for corner cases such as the above.This PR does include filetests that show that contexts are carriedthrough to spillslots and those appear in the metadata.Fixes #11285. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

968952ab - Cranelift: introduce a function inliner (#11210)

Thu, 10 Jul 2025 18:32:30 +0000

Cranelift: introduce a function inliner (#11210)* Cranelift: introduce a function inlinerThis comit adds "inlining as a library" to Cranelift; it does _not_ provide acomplete, off-the-shelf inlining solution. Cranelift's compilation context isper-function and does not encompass the full call graph. It does not know whichfunctions are hot and which are cold, which have been marked the equivalent of`#[inline(always)]` versus `#[inline(never)]`, etc... Only the Cranelift usercan understand these aspects of the full compilation pipeline, and these thingscan be very different between (say) Wasmtime and `cg_clif`. Therefore, thisinfrastructure does not attempt to define hueristics for when inlining aparticular call is likely beneficial. This module only provides hooks for theCranelift user to tell Cranelift whether a given call should be inlined or not,and the mechanics to inline a callee into a particular call site when the userdirects Cranelift to do so.This commit also creates a new kind of filetest that will always inline calls tofunctions that have already been defined in the file. This lets us exercise theinliner in filetests.Fixes https://github.com/bytecodealliance/wasmtime/issues/4127* Address review feedback* Require callee bodies are pre-legalized List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

099102d9 - Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)

Mon, 07 Jul 2025 17:25:40 +0000

Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegen (#11182)* Remove `expect(clippy::allow_attributes_without_reason)` from cranelift-codegenThis commit gets around to migrating the `cranelift-codegen` crate torequire a reason on lint directives and additionally switch to`#[expect]` where possible.prtest:full* Move x64-only item to x64 backend List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

cfe17cb1 - Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate (#11065)

Thu, 19 Jun 2025 00:24:34 +0000

Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crate (#11065)* Cranelift: Generate integer numeric ops and conversions for ISLE in the meta crateThis automatically generates operations and conversions for integer types foruse in ISLE.Supported types are: `{i,u}{8,16,32,64,128}`We generate* Comparisons (eq, ne, lt, lt_eq, gt, gt_eq)* Arithmetic operations (add, sub, mul, div, neg) * These each have checked, wrapping, and unwrapping variants* Bitwise operations (and, or, xor, shifts, counting leading/trailing zeros/ones)* A variety of predicates (is_zero, is_power_of_two, is_odd, etc...) * These generate both partial constructors and a handful of extractors* Conversions * These come in a variety of flavors: fallible, infallible, truncating, unwrapping, sign-reinterpretation * Fallible conversions are also available as an extractor* Fix copy paste* Rename `x_reinterpret_as_y` to `x_cast_[un]signed`* Collapse some fallible conversions in pulley lowering* Clean up pulley iconst lowering, make sure narrowest `xconst*` instruction is always used* Avoid an unnecessary truncation in riscv64 lowering* Use extractor instead of partial constructor in x64 `imm` rule* Clean up `op mem, imm` x64 lowering rules* Use `(i64_eq a b)` instead of `(u64_eq (i64_cast_unsigned a) (i64_cast_unsigned b))`* Rename `_unwrapping_` to `_` List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

efa236e5 - Cranelift: implement an "unwinder" crate and exception throws in filetests. (#10919)

Thu, 05 Jun 2025 01:39:23 +0000

Cranelift: implement an "unwinder" crate and exception throws in filetests. (#10919)This commit introduces the next major piece of machinery (after thepreviously-landed `try_call` support) that we will eventually use toimplement Wasm exceptions in Wasmtime. In particular, it implements ageneric unwinder as a new crate that supports (i) walking a stackproduced by Cranelift code, (ii) serializing Cranelift exceptionmetadata to compact tables (in a way very similar to address maps inWasmtime, so they will be mappable directly from disk), (iii) usingthese serialized tables to find handlers during a stack-walk, and (iv)jumping to handlers (i.e., actually unwinding). This crate is currentlyused in the filetests runner, and will next be used in Wasmtime.The commit first performs code-motion: it moves stack-walking code fromWasmtime to `cranelift-unwinder`. This itself has no functional effect,but isolates the code that understands contiguous sequences of Craneliftframes ("activations") from that which is specific to Wasmtime'sactivation delimiters and metadata.It then implements a compact exception-table format. This format usesthe `object` crate's mechanisms for directly referencing in-memoryarrays of little-endian `u32`s in a way that will allow us to findhandlers when mapping exception metadata directly from an ELF section ina `.cwasm` (for example). The format consists of four sorted `u32`arrays in a way that allows us to look up a callsite first, then searchits sorted array of handler offsets by tags.It next implements the actual unwind control flow: it contains anassembly stub for each supported architecture that transfers control toa PC, SP, and FP value "up the stack", with payload values placed in thepayload registers we have defined per our exception ABI in Cranelift.Finally, it puts these pieces together in the filetest runner. Note thatthe runtest does a lot "by hand": we don't have entry and exittrampolines as we do in Wasmtime, so the filetest contains threefunctions, with the middle one invoking the "throw hostcall" and entryand exit trampolines around it grabbing the appropriate entry/exit FPsand exit PC. The dance to call back to host code is also somewhatdelicate, as we haven't done this before. The `JITModule`'s linking +relocation support does not seem sufficient to properly define a symbol,so instead we scan for `func_addr` instructions referencing a well-knownname (`__cranelift_throw`) and replace them with `iconst`s with thefunction address at runtime, baking it in. This is somewhat ugly, but itworks. All of these filetest-specific details will be handled much morenicely in the Wasmtime version of this functionality, as we have properabstractions for entry/exit trampolines and hostcalls. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

2c1e1155 - winch(aarch64): Simplify constant handling, part 1/N (#10888)

Mon, 02 Jun 2025 23:38:29 +0000

winch(aarch64): Simplify constant handling, part 1/N (#10888)* winch(aarch64): implify constant handling, part 1/NThis commit is the first step toward simplifying constant handling,particularly for the aarch64 backend.The main highlights in this patch are:* Introduction of `ConstantPool` implemenetation on top of Cranlift primitives. The implemettaion is identical to the existing for x64, however, it's abstracted so that it can be easily consumed from any existing backend.* Usage of the constant pool from aarch64, which simplifies the loading of constants, particularly floating point constants.The main motivation behind this change is to _eventually_ detach theimplicit usage of the scatch register from constant loading as much aspossible, reducing the possibility of subtle bugs (like the onedescribed in https://github.com/bytecodealliance/wasmtime/pull/10829).Note that I have a work-in-progress branch from where all thesechanges are cherry picked from, to make everything easier to review.A side effect of this change, is the improvement to the codegeneration involving floating point constants. Prior to this change,multiple moves were involved, with this patch, at most 1 move isrequired and at worst one load is required.* Update disassembly tests* Apply refactored constant handling on top of shared float min/max implementation* `fmt` List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.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/cranelift/codegen/src/lib.rs

0e0a60ae - Define an RAII helper for generic take-and-replace borrow splitting (#10548)

Tue, 08 Apr 2025 19:48:08 +0000

Define an RAII helper for generic take-and-replace borrow splitting (#10548)* Define an RAII helper for generic take-and-replace borrow splittingFollow up to https://github.com/bytecodealliance/wasmtime/pull/10524#discussion_r2032164529* &mut T List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

3da7fc8e - [DI] Dump value label assignments in a table (#10549)

Tue, 08 Apr 2025 19:42:14 +0000

[DI] Dump value label assignments in a table (#10549)* Dump compilation start/end* [DI] Log value label ranges in a tableSample table:|Inst |IP |VL0 |VL1 |VL3 |VL4 |VL5 |VL7 |VL10 |VL11 |VL4294967294||--------|----|--------|---------|---------|--------|--------|--------|---------|--------|------------||Inst 0 |53 | | | | | | | | | | | | | | | | | | ||Inst 1 |53 | | | | | | | | | | | | | | | | | | ||Inst 2 |60 |v194|p2i|v232|p12i| | | | | | | | | | | | |v192|p7i ||Inst 3 |64 |* |p2i|* |p12i|v231|p13i| | | | | | | | | | |* |p7i ||Inst 4 |68 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 5 |72 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 6 |76 |* |p2i|* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 7 |87 |* | |* |p12i|* |p13i| | | | | | | | | | |* |p7i ||Inst 8 |92 |* | |* |p12i|* |p13i|v227|p0i| | | | | | | | |* |p15i ||Inst 9 |94 |* | |v204| |v204| |v204| |v204| |v204| |v204| |v204| |* |p15i ||Inst 10 |100 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 11 |105 |* | |* | |* | |* | |v226|p9i|* | |* | |* | |* |p15i ||Inst 12 |109 |* | |* | |* | |* | |* | |v225|p9i|* | |* | |* |p15i ||Inst 13 |114 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 14 |119 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 15 |125 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 16 |129 |* | |* | |* | |* | |* | |* | |v223|p11i|* | |* |p15i ||Inst 17 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 18 |134 |* | |* | |* | |* | |* | |* | |* | |* | |* |p15i ||Inst 19 |139 |* | |* | |* | |* | |* | |* | |* | |v222|p0i|* |p15i ||Inst 20 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* |p15i ||Inst 21 |143 |* | |* | |* | |* | |* | |* | |* | |* |p0i|* | |This will make it much easier to diagnose problems with incomplete/missing live ranges. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

82c0a09b - Simplify aegraphs by removing union-find and canonical eclass IDs. (#10471)

Wed, 26 Mar 2025 17:18:18 +0000

Simplify aegraphs by removing union-find and canonical eclass IDs. (#10471)I was recently re-thinking through some of the core data structuredesign in our aegraph implementation, and wondered: do we really needthe union-find data structure, the notion of "canonical" ID for aneclass separate from its latest ID (root of union-node tree), and thehashcons-key canonicalization using all of this? It's an awful lot ofcomplexity and has led to some fairly subtle bugs (e.g., #6126), and isgenerally unsatisfying.I had the realization: the only case where the distinction betweencanonical and latest ID matters is when we expand an eclass after itsinitial (eager) rewriting, which happens before we see its uses. If wehypothesize that this happens rarely, then it should be fine tocanonicalize based only on latest ID -- we shouldn't lose much (and wecan measure this loss empirically).The chief case where this kind of "late eclass expansion" still happensis: if we have some expression E1 that eventually rewrites to E2 viasome simplification, and E2 already exists earlier in the program, thenE1 will join the eclass. If we then have some `E3 := E1 + 1`, and later`E4 := E2 + 1`, we need the union-find canonicalization for E4 to GVN toE3. Otherwise, the latest ID for the eclass that eventually contains E1and E2 is different at the time that E3 uses it (and is GVN'd andrewritten) and when E4 does. Put another way: E3 captures a snapshot ofits operand's eclass before a new node joins it, and is neverreprocessed when that happens, so E3 remains distinct.But if the `E2 -> E1` rewrite is truly "directional" toward a betterrepresentation that we will always want to choose -- say, `x + 0 -> x`,or any constant-propagation in general -- then if the eager rewritingfor E2 produces E1's eclass ID directly *without* adding E2 to itsnodes, then all users will still canonicalize as before. This "onlyreturn the rewrite target, don't union with it" before is exactly our`subsume` operator.Put another way: subsumption prevents growing eclasses later, sosnapshots in time remain the latest, and everyone canonicalizes with thesame ID. We move to a true immutable data structure, with simplehashconsing with no magic.The rewrite semantics are then much simpler too: if any value ismarked "subsume", we pick it (pick an arbitrary one if multiple) as ourrewrite result; otherwise, create an eclass with the original rewriteinput and all rewrite outputs (by creating union-nodes in the DFG). Noauto-subsume or factoring in availability -- that's it. "Subsume" means:always pick the rewritten value, don't keep the original, and we use itwhenever that's unambiguously true for better canonicalization.Given that, it turns out that we can remove the union-find mechanismentirely. It also turns out that we can unify the scoped-hashmap for"effectful/idempotent ops" with the ordinary hashmap for pure ops;everything can be scoped. To get working LICM we do need to retain our"available block" mechanism, but only to insert values at a higher scopelevel in the scoped hashmap -- it is now heuristic, not load-bearing forcorrectness.I suspect that the fixpoint loop computing analysis results can go awaytoo, now that we truly don't update arguments -- we have a simpleimmutable data structure with everything snapshotted at creation -- butI haven't made that change yet.This change appears to be "in the noise" in both runtime and compiletime -- a Sightglass run on the default suite shows only```compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm Δ = 551234.50 ± 514580.62 (confidence = 99%) new.so is 1.00x to 1.01x faster than old.so! [61669181 72513567.85 98139932] new.so [60991071 73064802.35 120044089] old.soexecution :: cycles :: benchmarks/bz2/benchmark.wasm Δ = 232827.80 ± 204621.12 (confidence = 99%) old.so is 1.00x to 1.01x faster than new.so! [67208140 72812782.32 89996076] new.so [69531172 72579954.52 80530142] old.so```which seem like suitably small swings that are fine. Spot-checking theaegraph stats on the same function before-and-after shows the sameoptimizations happening in all functions I examined, and we see thecompile-tests showing no movement except for a value renumbering in onecase. So: no effect objectively, but deletes code and significantlysimplifies the core algorithm. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

1bb71d31 - Compute dominator tree using semi-NCA algorithm (#9603)

Thu, 09 Jan 2025 16:23:50 +0000

Compute dominator tree using semi-NCA algorithm (#9603)* Add dominator tree computed using semi-NCA algorithm.* Add dominator tree fuzz target* Move previous version of dominator tree to a separate file* Improve comments.* Use the new dominator tree in verifier.* Remove unused `iterators` module. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.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/cranelift/codegen/src/lib.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/cranelift/codegen/src/lib.rs

5b1a1edb - Enable --all-features and display feature requirements in Cranelift docs on docs.rs (#9493)

Tue, 22 Oct 2024 14:49:51 +0000

Enable --all-features and display feature requirements in Cranelift docs on docs.rs (#9493)* build docs for cranelift with all features enabled* build docs for cranelift-codegen with the feature all-arch* build docs for cranelift-codegen with the feature all-arch List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

ae92cb41 - Refactor `CallInfo` amongst Cranelift's backends (#9190)

Tue, 03 Sep 2024 18:53:40 +0000

Refactor `CallInfo` amongst Cranelift's backends (#9190)* Refactor backends to use the same `CallInfo`This commit refactors the various backends of cranelift, except fors390x, to use a shared definition of `CallInfo`. They were all alreadyquite similar and the main change here is to push platform-specificpieces into the instructions outside of `CallInfo`. This is intended tomake additions to `CallInfo` easier and require less refactoring in thefuture. Additionally this enables passing a `CallInfo` structure aroundinstead of passing around all of its components which helps reduce theamount of arguments to various functions.* s390x: Use the same `CallInfo` as other backendsThis commit refactors s390x the same way as the previous commit to usethe shared `CallInfo` that all other backends are using. This requiredmore refactoring on the s390x side of things to notably extract adedicated pseudo-instruction for `ElfTlsGetOffset` rather than bundlingit within the `Call` instruction.* Review comments and test fixes* Fold `ExternalName` into `CallInfo`As predicted instruction sizes got larger when outlining this on someplatforms so apply the same fix across all platforms by changing to`CallInfo` where the `T` will change depending on whether it's anindirect or direct call.* Update test expectations List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs

c0c3a68c - Cranelift: Remove the old stack maps implementation (#9159)

Wed, 21 Aug 2024 15:28:27 +0000

Cranelift: Remove the old stack maps implementation (#9159)They are superseded by the new user stack maps implementation. List of files: /wasmtime-44.0.1/cranelift/codegen/src/lib.rs