Support AVRTiny devices in AVR inline assembly by taiki-e · Pull Request #146901 · rust-lang/rust

taiki-e · 2025-09-22T17:59:44Z

Note: This is still draft and this depends on #146900 which adds necessary target feature. (The first commit is from it.)

Follow-up to #131323.

AVR has devices that reduce the number of registers, similar to RISC-V's RV32E, which have different ABI than default. This PR supports such devices in inline assembly.

Refs: AVR-GCC docs https://gcc.gnu.org/wiki/avr-gcc#Reduced_Tiny

On the Reduced Tiny cores (16 GPRs only) several modifications to the ABI above apply:

Call-saved registers are: R18–R19, R28–R29.
Fixed Registers are R16 (tmp_reg) and R17 (zero_reg).

Registers used to pass arguments to functions and return values from functions are R25...R20 (instead of R25...R8).
Values that occupy more than 4 registers are returned in memory (instead of more than 8 registers).
There is only limited library support both from libgcc and AVR-LibC, for example there is no float support and no printf support.

r? @Amanieu

@rustbot label +O-AVR +A-inline-assembly

tgross35 · 2025-09-22T18:44:48Z

Cc target maintainer @Patryk27

compiler/rustc_target/src/asm/avr.rs

Patryk27 · 2025-09-23T17:02:50Z

tests/ui/asm/avr/bad-reg.rs

+        asm!("", out("r15r14") _);
+        //[avrtiny]~^ ERROR on AVRTiny, r[2-15] are unavailable, r16 (scratch register) and r17 (zero register) are reserved by LLVM
+        asm!("", out("r17r16") _);
+        //[avrtiny]~^ ERROR on AVRTiny, r[2-15] are unavailable, r16 (scratch register) and r17 (zero register) are reserved by LLVM


nit: would be nice to have a different message for register pairs, otherwise it takes a moment to parse what the compiler is trying to say

Amanieu · 2025-09-26T17:59:12Z

r=me once the target features land

bors · 2025-11-05T08:32:17Z

☔ The latest upstream changes (presumably #147645) made this pull request unmergeable. Please resolve the merge conflicts.

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

…ingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: rust-lang#146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also rust-lang#146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (rust-lang#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See rust-lang#146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

@Patryk27

Rollup merge of #146900 - taiki-e:avr-target-feature, r=workingjubilee Add avr_target_feature This adds the following unstable target features (tracking issue: #146889): - The following two are particularly important for properly supporting inline assembly: - `tinyencoding`: AVR has devices that reduce the number of registers, similar to RISC-V's RV32E. This feature is necessary to support inline assembly in such devices. (see also #146901) - `lowbytefirst`: AVR's memory access is per 8-bit, and when writing 16-bit ports, the bytes must be written in a specific order. This order depends on devices, making this feature necessary to write proper inline assembly for such use cases. (see also llvm/llvm-project@2a52876) - The followings help recognizing whether specific instructions are available: - `addsubiw` - `break` - `eijmpcall` - `elpm` - `elpmx` - `ijmpcall` - `jmpcall` - `lpm` - `lpmx` - `movw` - `mul` - `rmw` - `spm` - `spmx` Of these, all except `addsubiw`, `break`, `ijmpcall`, `lpm`, `rmw`, `spm`, and `spmx` have [corresponding conditional codes in avr-libc](https://github.com/search?q=repo%3Aavrdudes%2Favr-libc+%2F__AVR_HAVE_%2F&type=code&p=1). LLVM also has `des` feature, but I excluded it from this PR because [DES](https://en.wikipedia.org/wiki/Data_Encryption_Standard) is insecure. - Report future-incompatible warning (#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases because SRAM is minimum requirement for non-assembly language in both avr-gcc and LLVM. - See #146900 (comment) for details. LLVM also has `smallstack`, `wrappingrjmp`, and `memmappedregs` features, but I skipped them because they didn't seem to belong to either of the above categories, but I might have missed something. (The feature names are match with [definitions in LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-21.1.0/llvm/lib/Target/AVR/AVRDevices.td).) cc @Patryk27 @Rahix r? workingjubilee @rustbot label +O-AVR +A-target-feature

taiki-e · 2026-02-07T17:30:02Z

The target feature PR has been merged and I rebased this PR.

apiraino · 2026-02-12T15:00:10Z

@bors r=Amanieu

rust-bors · 2026-02-12T15:00:13Z

📌 Commit b2dd13a has been approved by Amanieu

It is now in the queue for this repository.

@Amanieu

Support AVRTiny devices in AVR inline assembly Note: This is still draft and this depends on rust-lang#146900 which adds necessary target feature. (The first commit is from it.) --- Follow-up to rust-lang#131323. AVR has devices that reduce the number of registers, similar to RISC-V's RV32E, which have different ABI than default. This PR supports such devices in inline assembly. Refs: AVR-GCC docs https://gcc.gnu.org/wiki/avr-gcc#Reduced_Tiny > On the Reduced Tiny cores (16 GPRs only) several modifications to the ABI above apply: > > Call-saved registers are: R18–R19, R28–R29. Fixed Registers are R16 (__tmp_reg__) and R17 (__zero_reg__). > > Registers used to pass arguments to functions and return values from functions are R25...R20 (instead of R25...R8). Values that occupy more than 4 registers are returned in memory (instead of more than 8 registers). There is only limited library support both from libgcc and AVR-LibC, for example there is no float support and no printf support. r? @Amanieu @rustbot label +O-AVR +A-inline-assembly

@Amanieu

Support AVRTiny devices in AVR inline assembly Note: This is still draft and this depends on rust-lang#146900 which adds necessary target feature. (The first commit is from it.) --- Follow-up to rust-lang#131323. AVR has devices that reduce the number of registers, similar to RISC-V's RV32E, which have different ABI than default. This PR supports such devices in inline assembly. Refs: AVR-GCC docs https://gcc.gnu.org/wiki/avr-gcc#Reduced_Tiny > On the Reduced Tiny cores (16 GPRs only) several modifications to the ABI above apply: > > Call-saved registers are: R18–R19, R28–R29. Fixed Registers are R16 (__tmp_reg__) and R17 (__zero_reg__). > > Registers used to pass arguments to functions and return values from functions are R25...R20 (instead of R25...R8). Values that occupy more than 4 registers are returned in memory (instead of more than 8 registers). There is only limited library support both from libgcc and AVR-LibC, for example there is no float support and no printf support. r? @Amanieu @rustbot label +O-AVR +A-inline-assembly

…uwer Rollup of 11 pull requests Successful merges: - #146901 (Support AVRTiny devices in AVR inline assembly) - #150988 (Improve code suggestion for incorrect macro_rules! usage) - #152422 (Change query proc macro to be more rust-analyzer friendly) - #152496 (Fix multi-cgu+debug builds using autodiff by delaying autodiff till lto) - #152520 (Don't use `DepContext` in `rustc_middle::traits::cache`) - #152528 (Support serializing CodegenContext) - #152082 (Move tests) - #152444 (`-Znext-solver` Prevent committing unfulfilled unsized coercion) - #152486 (remove redundant backchain attribute in codegen) - #152529 (sparc64: enable abi compatibility test) - #152548 (reject inline const patterns pre-expansion)

Zalathar · 2026-02-13T00:59:30Z

Failed in rollup: #152551 (comment)

@bors r-

rust-bors · 2026-02-13T00:59:38Z

Commit b2dd13a has been unapproved.

This PR was contained in a rollup (#152551), which was also unapproved.

apiraino · 2026-02-16T11:47:34Z

@taiki-e can you investigate why this patch failed the rollup merge in CI (comment)? thanks

(if you're the right person for that)

taiki-e · 2026-02-16T16:24:22Z

From #152551 (comment):

rustc: /checkout/src/llvm-project/llvm/lib/Target/AVR/AVRExpandPseudoInsts.cpp:1345: bool (anonymous namespace)::AVRExpandPseudo::expand((anonymous namespace)::AVRExpandPseudo::Block &, (anonymous namespace)::AVRExpandPseudo::BlockIt): Assertion `MI.getOperand(0).getReg() == AVR::SP && "SP is expected as base pointer"' failed.
------------------------------------------

---- [ui] tests/ui/asm/avr/bad-reg.rs#avrtiny stdout end ----

failures:
    [ui] tests/ui/asm/avr/bad-reg.rs#avrtiny

It looks like the same one encountered in #146900 (comment).

Is LLVM trying to allocate to the stack pointer when there are insufficient assignable registers, causing an error?

@Patryk27 Any thoughts on this?

Patryk27 · 2026-02-16T19:15:00Z

Ah, that's interesting - 🔍

Patryk27 · 2026-02-16T19:32:04Z

I checked out your branch and it seems to work? 👀

; x test tests/ui/asm/avr/bad-reg.rs --force-rerun
Building bootstrap
    Finished `dev` profile [unoptimized] target(s) in 0.03s
Building stage1 compiler artifacts (stage0 -> stage1, x86_64-unknown-linux-gnu)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.13s
Creating a sysroot for stage1 compiler (use `rustup toolchain link 'name' build/host/stage1`)
Building stage1 library artifacts (stage1 -> stage1, x86_64-unknown-linux-gnu)
    Finished `dist` profile [optimized + debuginfo] target(s) in 0.02s
Building stage1 compiletest (stage0 -> stage1, x86_64-unknown-linux-gnu)
    Finished `release` profile [optimized + debuginfo] target(s) in 0.09s
Testing stage1 with compiletest suite=ui mode=ui (x86_64-unknown-linux-gnu)

running 2 tests
..

test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 20548 filtered out; finished in 65.69ms

Build completed successfully in 0:00:00

I do also happen to use a local version of LLVM, though (8cd31aa2c6c139b5f569b94c25462d7fcecdf7aa as of now) - I'll recheck tomorrow on whatever it is that rustc currently relies on.

rustbot assigned Amanieu Sep 22, 2025

taiki-e changed the title ~~Support AVRTiny devices AVR inline assembly~~ Support AVRTiny devices in AVR inline assembly Sep 22, 2025

This was referenced Sep 22, 2025

Tracking Issue for asm_experimental_arch #93335

Open

Add avr_target_feature #146900

Merged

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avrtiny branch from 2a9be64 to e2abd1e Compare September 22, 2025 18:20

Patryk27 reviewed Sep 23, 2025

View reviewed changes

compiler/rustc_target/src/asm/avr.rs Show resolved Hide resolved

Patryk27 reviewed Sep 23, 2025

View reviewed changes

taiki-e force-pushed the avrtiny branch from e2abd1e to 32e50a2 Compare February 7, 2026 12:56

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avrtiny branch from 32e50a2 to d768130 Compare February 7, 2026 13:58

This comment has been minimized.

Sign in to view

Support AVRTiny devices in AVR inline assembly

b2dd13a

taiki-e force-pushed the avrtiny branch from d768130 to b2dd13a Compare February 7, 2026 15:32

taiki-e marked this pull request as ready for review February 7, 2026 17:29

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 7, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 12, 2026

JonathanBrouwer mentioned this pull request Feb 12, 2026

Rollup of 9 pull requests #152547

Closed

JonathanBrouwer mentioned this pull request Feb 12, 2026

Rollup of 11 pull requests #152551

Closed

rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 13, 2026

Uh oh!

Conversation

taiki-e commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

tgross35 commented Sep 22, 2025

Uh oh!

Uh oh!

Patryk27 Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Amanieu commented Sep 26, 2025

Uh oh!

bors commented Nov 5, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

taiki-e commented Feb 7, 2026

Uh oh!

apiraino commented Feb 12, 2026

Uh oh!

rust-bors bot commented Feb 12, 2026

Uh oh!

Zalathar commented Feb 13, 2026

Uh oh!

rust-bors bot commented Feb 13, 2026

Uh oh!

apiraino commented Feb 16, 2026

Uh oh!

taiki-e commented Feb 16, 2026

Uh oh!

Patryk27 commented Feb 16, 2026

Uh oh!

Patryk27 commented Feb 16, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

taiki-e commented Sep 22, 2025 •

edited

Loading

Patryk27 Sep 23, 2025 •

edited

Loading