<?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 lib.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>63330f11 - cranelift-assembler-x64: no_std support (#12235)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#63330f11</link>
        <description>cranelift-assembler-x64: no_std support (#12235)* cranelift-assembler-x64: no_std support* cargo fmt* Update cranelift/assembler-x64/src/xmm.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Update cranelift/assembler-x64/src/imm.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Update cranelift/assembler-x64/src/api.rsCo-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;* Reorder import of alloc* #![no_std]* revert main.rs* cargo fmt* remove core feature* Fix CI---------Co-authored-by: bjorn3 &lt;17426603+bjorn3@users.noreply.github.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Mon, 05 Jan 2026 15:50:37 +0000</pubDate>
        <dc:creator>SSD &lt;96286755+the-ssd@users.noreply.github.com&gt;</dc:creator>
    </item>
<item>
        <title>66b4bf32 - x64: handle ISA features more completely (#11272)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#66b4bf32</link>
        <description>x64: handle ISA features more completely (#11272)* asm: generate boolean terms of CPU featuresAs discussed [here], we will soon need the ability to express morecomplex combinations of CPU features. These are best expressed asboolean terms: e.g., `(32-bit OR 64-bit) AND ...`, `(32-bit OR 64-bit)AND ((AVX512VL AND AVX512F) OR AVX10.1)`. This change modifies thegenerated code to have a `Inst::is_available` method which contains aRust-ified version of the instruction&apos;s boolean term. To do this, we nowpass in a `Features` trait, which the instruction can query to see ifits desired feature set is available.[here]: https://bytecodealliance.zulipchat.com/#narrow/channel/217117-cranelift/topic/boolean.20terms.20for.20x64.20features* x64: wire up `Inst::is_available` in CraneliftThis change makes us of the assembler&apos;s new generated`Inst::is_available` methods to check an instruction&apos;s feature set in amore succinct (and likely quicker) way. Unfortunately, this does notallow us to print the missing ISA requirements on failure--something toaddress later.* Rename `Features` to `AvailableFeatures`* Remove unused `InstructionSet`* asm: fix all feature definitionsThis is a mechanical transformation converting all instructiondefinitions. Now, instructions should have a correct boolean termdescribe the features required: e.g., `(_64b | compat) &amp; avx`.* x64: replace `use_*` with `has_*` when checking ISA featuresIn Cranelift, the `has_*` flags of `isa::x64::settings::Flags` indicatethat the CPU _has_ some capability; the `use_*` flags indicate thatCranelift _should emit_ instructions using those capabilities. Further,the `use_*` flags may turned on by the presence of more than one `has_*`flags; e.g., when `has_avx` and `has_avx2` are available, `use_avx2` isenabled.Now that Cranelift&apos;s new x64 assembler understands boolean terms, we nolonger need the `use_*` flags for checking if an instruction can beemitted: instead, we should use the `has_*` flags and rely on the logicencoded in `Inst::is_available`.* asm: materialize `Features` via `Inst::features`For better error messages (and just for general use of CPU features, seediscussion [here]), this change adds `Inst::features`--a way toexplicitly examine the boolean term for an instruction. This functionreturns a `&amp;&apos;static Features` that contains the `AND` and `OR` branchesdefining when an instruction is available. This is all generated intosomething that looks like:```rustpub fn features(&amp;self) -&gt; &amp;&apos;static Features {    const F1: &amp;&apos;static Features = &amp;Features::Feature(Feature::_64b);    const F2: &amp;&apos;static Features = &amp;Features::Feature(Feature::compat);    const F0: &amp;&apos;static Features = &amp;Features::Or(F1, F2);    F0}```This change makes use of `for_each_feature` more: we build up the`AvailableFeatures` trait and the `Feature` enum from it. This should bea bit more direct than searching through the generated code (?).[here]: https://github.com/bytecodealliance/wasmtime/pull/11272#discussion_r2214465871

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 06 Aug 2025 14:32:36 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>239f4a89 - x64: EVEX Encoding for new assembler (#11153)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#239f4a89</link>
        <description>x64: EVEX Encoding for new assembler (#11153)* evex prefix for new assembler, vaddpd inst, prtest:full* review: refactor `VexLength` and `EvexLength` into a single `Length`* review: fix order of instruction definition to match manualAlso, adds some missing `.r()` helpers for consistency.* review: remove opmask registers and mask kind for nowThis will require more work to expose these as special,runtime-available flags on the generated instruction.* review: remove as-yet unknown operand patterns for EVEXIt&apos;s likely they will share logic with the VEX patterns but we canrefactor that in the future.* review: fix up the `mmm` bit field, document* fix: use new `Length` name in doc tests* review: rename `VexW` to `WBit`* Ensure VEX instructions cannot be defined with `Length::L512`* Use `WBit` in REX instructions---------Co-authored-by: Andrew Brown &lt;andrew.brown@intel.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 16 Jul 2025 22:26:49 +0000</pubDate>
        <dc:creator>Rahul &lt;rahul.s.chaphalkar@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>79095df3 - x64: Refactor emission of LoadExtName  (#11124)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#79095df3</link>
        <description>x64: Refactor emission of LoadExtName  (#11124)* x64: Expand symbol-related tests* x64: Refactor emission of `LoadExtName`Don&apos;t use raw bytes when emitting this instruction but instead usesymbolic assembler directives to avoid needing to hardcode bytes. Thisadditionally fixes an issue where with `colocated` symbols the offset ofthe symbol was not taken into account (but for Wasmtime it&apos;s always been0 so this otherwise hasn&apos;t come up so far)* Fix emit tests* Update test expectation* Fuse `KnownOffsetTable` and `CodeSink` in the new assemblerEnables a `CodeSink` to know about all offsets, not just those againstlabels. Resolves an issue where the fuzzing code sink was otherwiseunaware of `DeferredTarget::None`.* Review comments

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 25 Jun 2025 18:06:53 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>4955f5a7 - x64: Migrate `mulx` to the new assembler (#10887)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#4955f5a7</link>
        <description>x64: Migrate `mulx` to the new assembler (#10887)* x64: Migrate `mulx` to the new assemblerThis is an interesting instruction as it has a relatively unique shapecompared to many others. The VEX encoding is used to give it a 3-operandform, although it still has an implicit 4th operand as well. The otherunique part about this instruction is that if the two write-onlyoperands are the same then that has a different semantic meaning than ifthey are different.Modeling the two-output form of the instruction was pretty easy, theonly changes needed were to add the `r32a` and `r32b` locations aspreviously only `r32` was available. Modeling the one-output form of theinstruction led to a &quot;hook&quot; where these instructions specify that theyuse a custom regalloc function. That skips the auto-generated regallocentirely and defers to a new `custom` submodule in the assembler crate.These custom variants handle only having a single write operand on theinstruction.* Fix fuzz build

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Mon, 02 Jun 2025 20:14:46 +0000</pubDate>
        <dc:creator>Alex Crichton &lt;alex@alexcrichton.com&gt;</dc:creator>
    </item>
<item>
        <title>e5caad1b - x64: convert `movq` (#10871)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#e5caad1b</link>
        <description>x64: convert `movq` (#10871)* asm: add an `imm64` operand* x64: add scalar moves* asm: fix up `mov` immediates for Capstone* x64: convert `movq` instruction* pcc: remove ability to check `Mov64MR` moves* x64: bless tests using `movq`* winch: convert `movq` instruction* pcc: disable tests for now* review: model partial written-to locations with `w`

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 30 May 2025 23:45:07 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>f3763e45 - Initial support for vex encoding for the new assembler. (#10754)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#f3763e45</link>
        <description>Initial support for vex encoding for the new assembler. (#10754)* Initial support for vex encoding for the new assembler.* Addressing many PR comments: Remove ymm and zmm support, cleanup, etc---------Co-authored-by: Andrew Brown &lt;andrew.brown@intel.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 23 May 2025 22:51:51 +0000</pubDate>
        <dc:creator>Johnnie Birch &lt;johnnie.l.birch.jr@intel.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/cranelift/assembler-x64/src/lib.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/cranelift/assembler-x64/src/lib.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>d9468c6e - asm: implement write-only operands (#10759)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#d9468c6e</link>
        <description>asm: implement write-only operands (#10759)* asm: implement write-only operandsThis change adds support to the new assembler for write-only operands.This implementation appeared first in [#10754] but is split out here tounblock implementation of instructions that require it: multiplication,conversions, moves, etc. This starts roughly the same as what wasimplemented for write-only XMMs in [#10754] but includes support forwrite-only GPRs as well and generates the temporary registers which areneeded.[#10754]: https://github.com/bytecodealliance/wasmtime/pull/10754Co-authored-by: Johnnie Birch &lt;johnnie.l.birch.jr@intel.com&gt;* fix: use `to_reg()` to extract the Cranelift type from `Writable`---------Co-authored-by: Johnnie Birch &lt;johnnie.l.birch.jr@intel.com&gt;

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 09 May 2025 21:58:03 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>19000eea - asm: refactor how REX prefixes are emitted (#10745)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#19000eea</link>
        <description>asm: refactor how REX prefixes are emitted (#10745)This does not change functionality; instead, it reorganizes how REXprefixes were encoded by the assembler to simplify code generation.`RexFlags` now becomes the more-correct `RexPrefix` and constructorslike `RexPrefix::two_op` build the necessary byte for emission with`RexPrefix::encode`.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 07 May 2025 21:56:59 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>1c940b7e - Inline assembler-x64 `generated_files` in `main.rs` (#10739)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#1c940b7e</link>
        <description>Inline assembler-x64 `generated_files` in `main.rs` (#10739)The public function `generated_files` in `cranelift-assembler-x64` makesthe generated `rlib` non-deterministic because it contains the fullpaths of generated files. But this function is only used in `main.rs` ofthe same crate, so this change inlines it there to keep the library artifactdeterministic while maintaining the same behavior.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 07 May 2025 13:54:15 +0000</pubDate>
        <dc:creator>Adam Bratschi-Kaye &lt;adam.bratschikaye@dfinity.org&gt;</dc:creator>
    </item>
<item>
        <title>420f7453 - asm: plumb fixed registers through (#10629)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#420f7453</link>
        <description>asm: plumb fixed registers through (#10629)* asm: plumb fixed registers throughThis change introduces a new `Fixed` wrapper type that allows us toplumb fixed registers through the assembler. These instructions are notyet used by `cranelift-codegen`, but will be necessary at some point asdescribed in [#10238]. The end result of this is that up at the`cranelift-codegen` level, fixed registers should look likerun-of-the-mill virtual registers using the appropriate types, but downin `cranelift-assembler-x64` we panic if the register allocator does notgive them the correct register.[#10238]: https://github.com/bytecodealliance/wasmtime/issues/10238* fix: reduce `size_of::&lt;Inst&gt;` testIt is unclear why adding more `Fixed&lt;R&gt;` fields would somehow _reduce_the size of `Inst`. What is quite clear is that I do not understand howRust chooses to lay out these fields.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Tue, 22 Apr 2025 00:25:48 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>6ad0840d - asm: allow printing of virtual registers (#10389)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#6ad0840d</link>
        <description>asm: allow printing of virtual registers (#10389)* Rename module: `reg` to `gpr`* Override `to_string` implementation for `cranelift-codegen` types* Add pretty-printing tests

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 14 Mar 2025 14:50:27 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>bce7f205 - meta: move all ISLE-related generated code to `cranelift-codegen-meta` (#10352)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#bce7f205</link>
        <description>meta: move all ISLE-related generated code to `cranelift-codegen-meta` (#10352)* meta: move all ISLE-related generated code to `cranelift-codegen-meta`Previously, the new `cranelift-assembler-x64` crate would generate theassembler Rust code, the ISLE integration code, and the ISLE&apos;saccompanying Rust macro all in the same crate. Because these last twofiles were generated in the assembler&apos;s `OUT_DIR`, they caused issuesfor deterministic builds that expect those files in`cranelift-codegen`&apos;s `OUT_DIR` (see #10348). This change fixes that bymoving all of the assembler&apos;s generated integration code, the ISLEinstruction definitions and their accompanying Rust macro, to the`cranelift-codegen-meta` crate.This has the added advantage that `cranelift-assembler-x64` now canfocus exclusively on being an assembler and not being concerned with theISLE integration, which is substantial.* Move lint `allow` to problem siteApparently allowing unused variables for unimplemented parts of fixedregister instructions will not work at the macro scope; this moves the`allow` to the offending line.* Remove `rustfmt` of generated assembler code

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Sat, 08 Mar 2025 00:40:58 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>e33c4269 - asm: sse orpd implementation (#10273)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#e33c4269</link>
        <description>asm: sse orpd implementation (#10273)* sse orpd implementationassembler integration with isleformatadd clippy reason, reorder avx priority in islebless tests for orpdcreate separate xmm modulevalidate function rewrite sse conditionadd quote from manual for sse prefixformat changesmove Xmm bits under Reg* use new isle constructors for sse* remove unused function* minor changes

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Sat, 01 Mar 2025 06:49:48 +0000</pubDate>
        <dc:creator>Rahul &lt;rahul.s.chaphalkar@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>0c846961 - ci: generate a list of generated files (#10267)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#0c846961</link>
        <description>ci: generate a list of generated files (#10267)* ci: generate a list of generated filesThis fix is necessary for Windows users who may be using absolute-pathtarget directories: the previous solution, separating the paths by `:`,runs into issues with Windows absolute paths (e.g., `C:\...`). Thischange is similar to #10266 but should avoid any further OScompatibility issues during a hypothetical cross-compilation.prtest:full* fix: debug string

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 21 Feb 2025 01:42:20 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>a07abc88 - asm: switch to using workspace clippy settings (#10230)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#a07abc88</link>
        <description>asm: switch to using workspace clippy settings (#10230)* asm: switch to using workspace clippy settingsThis removes all the custom clippy allowances and just adopts theproject&apos;s Clippy settings. This was suggested over in [#10216].[#10216]: https://github.com/bytecodealliance/wasmtime/pull/10216#discussion_r1951135923* fix: add one more allow reason

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Fri, 14 Feb 2025 00:36:05 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>b0b5d8f7 - asm: fix sign-extended immediates (#10216)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#b0b5d8f7</link>
        <description>asm: fix sign-extended immediates (#10216)* asm: replace `emit_simm` with `Imm*::encode`* asm: expand fuzz doc comment* asm: pretty print sign-extended immediatesAs mentioned in #10200, `capstone` has a peculiar way of pretty-printingimmediates, especially signed immediates. It is simpler (and perhapsmore clear) for us to just print immediates in one consistent format:`0xffff...`, e.g. This change parses capstone&apos;s pretty-printedimmediates and converts them to our simpler format if the first attemptto match this assembler&apos;s output with `capston` fails.* asm: add types for sign-extended immediatesAs pointed out in #10200, it could be confusing for users for`cranelift-assembler-x64` to pass unsigned integers to certain assemblerinstructions and have them unexpectedly sign-extended. Well, it can&apos;t betoo surprising since these instructions have a `_sx*` suffix, but thischange implements @alexcrichton&apos;s additional suggestion to createseparate types for the immediates that may be sign-extended.These new types (`Simm8`, `Simm16`, `Simm32`) are quite similar to theirvanilla counterparts (`Imm8`, `Imm16`, `Imm32`) but have additionalsign-extension logic when pretty-printed. This means the vanillaversions can be simplified and the pre-existing `Simm32` is renamed tothe more appropriate `AmodeOffset`.* clippy: fix casts, find pattern

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Thu, 13 Feb 2025 22:17:17 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>d7d605c2 - asm: re-allow prop-testing with `cargo test` (#10185)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#d7d605c2</link>
        <description>asm: re-allow prop-testing with `cargo test` (#10185)In #10110, I originally intended to use `arbitrary` implementations intwo ways: for long-running fuzz testing (e.g., with OSS-Fuzz) but alsofor quick property testing with `cargo test`. This latter use case couldreplace the tedious emit tests we had to write in `cranelift-codegen`_and_ find corner cases that we otherwise might not explore. It helpedme during development: just run `cargo test` to check if anything isobviously wrong. `arbtest` seemed to be able to run ~1000 test cases andfound mistakes well within the one second time limit I gave it.@alexcrichton improved #10110 by avoiding `Arbitrary` implementationseverywhere and unconditionally depending on the `arbitrary` crate. Thiswas the right change, but it removed the ability to property test using`cargo test`. What this change does is retain the general intent of hischange (no extra dependencies) but add `Arbitrary` implementations for`cfg(test)` as well to run property tests during `cargo test`.The only downside I see here is the added complexity when conditionallycompiling the fuzz-related bits: `#[cfg(any(test, feature = &quot;fuzz&quot;))]`.Perhaps there is a better way to do this, but this seemed to work fine.Let me know what you think.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Wed, 05 Feb 2025 16:00:53 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
<item>
        <title>99622abe - asm: prepare docs for publishing (#10178)</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs#99622abe</link>
        <description>asm: prepare docs for publishing (#10178)This change is motivated by staring at the output of `cargo doc` for the`cranelift-assembler-x64` crate. In order to write a sensible top-levelexample, I felt it was best to refactor how we construct theinstructions: this removes the `build` module and adds conventional`&lt;inst_name&gt;::new` functions to each instruction. Also, a generated`From` implementation makes it easier to convert to an `Inst`.This change has other doc-related refactorings and tweaks, but shouldnot change any functionality.

            List of files:
            /wasmtime-44.0.1/cranelift/assembler-x64/src/lib.rs</description>
        <pubDate>Tue, 04 Feb 2025 17:41:40 +0000</pubDate>
        <dc:creator>Andrew Brown &lt;andrew.brown@intel.com&gt;</dc:creator>
    </item>
</channel>
</rss>
