Add avr_target_feature by taiki-e · Pull Request #146900 · rust-lang/rust

taiki-e · 2025-09-22T17:42:22Z

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 Support AVRTiny devices in AVR inline assembly #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. LLVM also has des feature, but I excluded it from this PR because DES is insecure.
Report future-incompatible warning (The ABI of float types can be changed by -Ctarget-feature #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 Add avr_target_feature #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.)

cc @Patryk27 @Rahix
r? workingjubilee

@rustbot label +O-AVR +A-target-feature

rustbot · 2025-09-22T17:42:28Z

workingjubilee is currently at their maximum review capacity.
They may take a while to respond.

taiki-e · 2025-09-23T11:15:56Z

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

Patryk27 · 2025-09-23T16:45:57Z

compiler/rustc_target/src/target_features.rs

+static AVR_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[
+    // tidy-alphabetical-start
+    ("addsubiw", Unstable(sym::avr_target_feature), &[]),
+    ("break", Unstable(sym::avr_target_feature), &[]),


nit: what about name collisions? 👀

The RFC doesn't seem to mention this, but I can see AVR's break (or other "generic" word like mul) accidentally colliding with another arch in future - on the other hand, keeping the mapping 1:1 with LLVM (FeatureBREAK in this case) is important as well, IMO.

Other than that LGTM.

Target feature name collisions with other architectures are fine. (e.g., the aes target feature exists on x86/x86_64 (AES-NI) and arm/aarch64/arm64ec (FEAT_AES) respectively.)

taiki-e · 2025-09-24T14:37:33Z

As for sram, this is the minimum requirement for C/C++ in both avr-gcc and clang (llvm/llvm-project@4bf6e83), and likely for Rust as well, so it is probably better to handle this not as a target feature here, but another way (such as rejecting compilation if it is not enabled).

Looking at the LLVM issue, in Rust, I guess it might work if we use no_main and put all processing inside global_asm and/or external assemblies...

workingjubilee · 2025-09-27T23:20:48Z

cc @rust-lang/lang informational-only: letting you know about this target's features because it is particularly interesting in terms of it being on the boundary of what Rust can support.

I think that we should indeed either ignore it or just error if someone tries to say -Ctarget-feature=-sram to the compiler. It is a rare case of "Here's a nickel, kid, go buy yourself a real computer" being an actually literally valid suggestion, even with 2025's inflation. The newest "AVR1" chips are so old that even products with 25-year lifecycles should have killed them off by now.

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

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

workingjubilee · 2025-11-15T20:15:34Z

This is waiting on "-sram should error", I think?

@rustbot author

rustbot · 2026-01-09T01:43:42Z

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

taiki-e · 2026-01-09T14:52:54Z

Changed sram to Forbidden and added it to abi_required_features, to report future-incompatible warning (#116344) for -C target-feature=-sram and -C target-cpu=<device_without_sram> cases.

@rustbot ready

rust-bors · 2026-01-15T00:58:34Z

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

workingjubilee · 2026-02-04T21:30:41Z

T-lang has to approve these features being stable, last I checked, but I believe we can accept this for now as this is unstable and the same "eh, let's throw them in" basis was used for the initial add of every other architecture's features.

@bors r+

rust-bors · 2026-02-04T21:30:44Z

📌 Commit febe008 has been approved by workingjubilee

It is now in the queue for this repository.

workingjubilee · 2026-02-04T21:31:49Z

tests/ui/abi/avr-sram.disable_sram.stderr

+warning: target feature `sram` cannot be disabled with `-Ctarget-feature`: devices that have no SRAM are unsupported
+   |
+   = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+   = note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
+
+warning: target feature `sram` must be enabled to ensure that the ABI of the current target can be implemented correctly
+   |
+   = note: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
+   = note: for more information, see issue #116344 <https://github.com/rust-lang/rust/issues/116344>
+
+warning: 2 warnings emitted
+


This should probably proactively become a hard error before stabilizing.

@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

Rollup of 15 pull requests Successful merges: - #151431 (Add new unstable attribute: `#[export_visibility = ...]`.) - #146900 (Add avr_target_feature) - #152033 (Rename trait `DepNodeParams` to `DepNodeKey`) - #152142 (Convert to inline diagnostics in `rustc_hir_typeck`) - #152020 (Remove dummy loads on offload codegen) - #152023 (Some `rustc_query_system` cleanups) - #152068 (Convert to inline diagnostics in `rustc_resolve`) - #152081 (Port depgraph testing attributes to parser) - #152090 (Port reexport_test_harness_main to attr parser) - #152105 (Convert to inline diagnostics in `rustc_ast_lowering`) - #152108 (Convert to inline diagnostics in `rustc_expand`) - #152114 (Convert to inline diagnostics in `rustc_mir_transform`) - #152115 (Convert to inline diagnostics in `rustc_metadata`) - #152116 (Remove rustdoc GUI flaky test) - #152128 (Adopt matches-logical-or-141497.rs to LLVM HEAD) Failed merges: - #152070 (Convert to inline diagnostics in `rustc_pattern_analysis`) - #152106 (Convert to inline diagnostics in `rustc_ast_passes`) - #152109 (Convert to inline diagnostics in `rustc_errors`) - #152117 (Convert to inline diagnostics in `rustc_trait_selection`) - #152118 (Convert to inline diagnostics in `rustc_codegen_ssa`) - #152119 (Convert to inline diagnostics in `rustc_middle`) - #152126 (Convert to inline diagnostics in `rustc_mir_build`) - #152131 (Port rustc_no_implicit_bounds attribute to parser.)

@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

Rollup of 19 pull requests Successful merges: - #146900 (Add avr_target_feature) - #150379 (Return `ExitCode` from `rustc_driver::main` instead of calling `process::exit`) - #152033 (Rename trait `DepNodeParams` to `DepNodeKey`) - #152142 (Convert to inline diagnostics in `rustc_hir_typeck`) - #152145 (Disable flaky test `oneshot::recv_timeout_before_send`) - #152020 (Remove dummy loads on offload codegen) - #152023 (Some `rustc_query_system` cleanups) - #152068 (Convert to inline diagnostics in `rustc_resolve`) - #152081 (Port depgraph testing attributes to parser) - #152090 (Port reexport_test_harness_main to attr parser) - #152105 (Convert to inline diagnostics in `rustc_ast_lowering`) - #152108 (Convert to inline diagnostics in `rustc_expand`) - #152110 (Fix incorrect RSS on systems with non-4K page size) - #152111 (bootstrap: exclude hexagon-unknown-qurt from llvm-libunwind default) - #152114 (Convert to inline diagnostics in `rustc_mir_transform`) - #152115 (Convert to inline diagnostics in `rustc_metadata`) - #152116 (Remove rustdoc GUI flaky test) - #152118 (Convert to inline diagnostics in `rustc_codegen_ssa`) - #152128 (Adopt matches-logical-or-141497.rs to LLVM HEAD) Failed merges: - #152070 (Convert to inline diagnostics in `rustc_pattern_analysis`) - #152106 (Convert to inline diagnostics in `rustc_ast_passes`) - #152109 (Convert to inline diagnostics in `rustc_errors`) - #152117 (Convert to inline diagnostics in `rustc_trait_selection`) - #152119 (Convert to inline diagnostics in `rustc_middle`) - #152126 (Convert to inline diagnostics in `rustc_mir_build`) - #152131 (Port rustc_no_implicit_bounds attribute to parser.)

JonathanBrouwer · 2026-02-05T07:32:25Z

@bors r-
#152149 (comment)

rust-bors · 2026-02-05T07:32:33Z

Commit febe008 has been unapproved.

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

rustbot · 2026-02-05T11:06:18Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

taiki-e · 2026-02-05T11:10:04Z

~~Hmm, it seems that the error in #152149 (comment) is a bug LLVM AVR backend probably introduced in LLVM 22:~~ EDIT: see #146900 (comment)

rustc: /checkout/src/llvm-project/llvm/lib/Target/AVR/AVRExpandPseudoInsts.cpp:1364: 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.

workingjubilee · 2026-02-05T20:56:47Z

RIP.

workingjubilee · 2026-02-05T20:58:21Z

Does that potentially affect all AVR code?

We aren't passing through the feature, right?

taiki-e · 2026-02-06T00:27:28Z

Hmm, it seems that the error in #152149 (comment) is a bug LLVM AVR backend probably introduced in LLVM 22:

Looking more closely at the logs, the error only occurs when SRAM is disabled, so it seems this is simply an example of "-sram is incompatible with Rust".

And that error is likely occurring while compiling Rust code within minicore, so I suspect it could be avoided by removing the dependency on minicore.

rust/tests/ui/abi/avr-sram.rs

Line 18 in 5cab3e4

extern crate minicore;

rust-log-analyzer · 2026-02-06T01:58:51Z

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

REPOSITORY                                   TAG       IMAGE ID       CREATED      SIZE
ghcr.io/dependabot/dependabot-updater-core   latest    b72a662c47e3   6 days ago   790MB
=> Removing docker images...
Deleted Images:
untagged: ghcr.io/dependabot/dependabot-updater-core:latest
untagged: ghcr.io/dependabot/dependabot-updater-core@sha256:57ef9cc45f72cc4258ee1baa8243bc3cd55c0a0e570b6768c37346247be35f0d
deleted: sha256:b72a662c47e31df2e7bf59368b2b83be239f02a1baa721393717711a1a719df9
deleted: sha256:3e13ccd80f19769f39008cfc6549938e1ea4905f47b028c1df2dd6085191386c
deleted: sha256:842807995a512b2c5a9b241a3aecdbe79af6b0642d96fa5460cfcf0c9d8be295
deleted: sha256:0f9074b9f46f4570eb7cb4b65fcb3c3d909f9b1d14ca66b30508117b6deda303
deleted: sha256:2ca99cb9251d19157c56b5d91c8961bb4b35196a5ca9b4ffdccbf24abbfe2a5f
---
tests/ui/drain_collect.fixed ... ok
tests/ui/double_parens.rs ... ok
tests/ui/duplicate_underscore_argument.rs ... ok
tests/ui/duplicated_attributes.rs ... ok
tests/ui/duration_suboptimal_units.rs ... ok
tests/ui/duration_suboptimal_units_days_weeks.rs ... ok
tests/ui/duration_subsec.rs ... ok
tests/ui/duration_suboptimal_units_days_weeks.fixed ... ok
tests/ui/duration_suboptimal_units.fixed ... ok
tests/ui/double_parens.fixed ... ok
tests/ui/duration_subsec.fixed ... ok
tests/ui/else_if_without_else.rs ... ok
tests/ui/elidable_lifetime_names.rs ... ok
tests/ui/eager_transmute.rs ... ok
---
..............................................     (146/146)

======== tests/rustdoc-gui/search-filter.goml ========

[ERROR] line 48: Error: The CSS selector "#search-tabs .count.loading" still exists: for command `wait-for-false: "#search-tabs .count.loading"`
    at <file:///checkout/obj/build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/test_docs/index.html?search=test>

======== tests/rustdoc-gui/search-result-display.goml ========

[WARNING] line 39: Delta is 0 for "x", maybe try to use `compare-elements-position` instead?

rustbot assigned workingjubilee Sep 22, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 22, 2025

rustbot added A-target-feature Area: Enabling/disabling target features like AVX, Neon, etc. O-AVR Target: AVR processors (ATtiny, ATmega, etc.) labels Sep 22, 2025

This was referenced Sep 22, 2025

Tracking Issue for avr_target_feature #146889

Open

Support AVRTiny devices in AVR inline assembly #146901

Draft

Patryk27 reviewed Sep 23, 2025

View reviewed changes

rustbot 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-review Status: Awaiting review from the assignee but also interested parties. labels Nov 15, 2025

taiki-e force-pushed the avr-target-feature branch from 18d8866 to 7763f18 Compare January 9, 2026 01:43

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avr-target-feature branch from 7763f18 to e3f2d28 Compare January 9, 2026 01:51

This comment has been minimized.

Sign in to view

taiki-e force-pushed the avr-target-feature branch 2 times, most recently from 0d13763 to 75de66b Compare January 9, 2026 13:38

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 Jan 9, 2026

taiki-e force-pushed the avr-target-feature branch from 75de66b to e940165 Compare January 15, 2026 02:06

This comment has been minimized.

Sign in to view

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 4, 2026

workingjubilee reviewed Feb 4, 2026

View reviewed changes

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 15 pull requests #152144

Closed

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 18 pull requests #152147

Closed

Zalathar mentioned this pull request Feb 5, 2026

Rollup of 19 pull requests #152149

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 5, 2026

Add avr_target_feature

8cbc623

taiki-e force-pushed the avr-target-feature branch from febe008 to 5cab3e4 Compare February 5, 2026 11:06

taiki-e force-pushed the avr-target-feature branch from 5cab3e4 to ab23741 Compare February 6, 2026 00:28

Require sram target feature on AVR

895ea0c

taiki-e force-pushed the avr-target-feature branch from ab23741 to 895ea0c Compare February 6, 2026 00:29

[DO NOT MERGE] re-add minicore for test

f349668

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!

rustbot commented Sep 22, 2025

Uh oh!

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

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!

taiki-e Sep 24, 2025

Choose a reason for hiding this comment

Uh oh!

taiki-e commented Sep 24, 2025

Uh oh!

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

Uh oh!

Uh oh!

bors commented Nov 5, 2025

Uh oh!

workingjubilee commented Nov 15, 2025

Uh oh!

rustbot commented Jan 9, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

taiki-e commented Jan 9, 2026

Uh oh!

rust-bors bot commented Jan 15, 2026

Uh oh!

This comment has been minimized.

This comment has been minimized.

workingjubilee commented Feb 4, 2026

Uh oh!

rust-bors bot commented Feb 4, 2026

Uh oh!

workingjubilee Feb 4, 2026

Choose a reason for hiding this comment

Uh oh!

JonathanBrouwer commented Feb 5, 2026

Uh oh!

rust-bors bot commented Feb 5, 2026

Uh oh!

rustbot commented Feb 5, 2026

Uh oh!

taiki-e commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

workingjubilee commented Feb 5, 2026

Uh oh!

workingjubilee commented Feb 5, 2026

Uh oh!

taiki-e commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-log-analyzer commented Feb 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

taiki-e commented Sep 22, 2025 •

edited

Loading

taiki-e commented Sep 23, 2025 •

edited

Loading

Patryk27 Sep 23, 2025 •

edited

Loading

workingjubilee commented Sep 27, 2025 •

edited

Loading

taiki-e commented Feb 5, 2026 •

edited

Loading

taiki-e commented Feb 6, 2026 •

edited

Loading