Add information about group a lint belongs to #140794

karolzwolak · 2025-05-08T11:23:52Z

Description

Fixes: #65464

Changes Made

Extended the default lint settings message to include the lint group they belong to
Modified the proposed fix message wording from "part of" to "implied by" for better accuracy
- Old message: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
- New message: `#[warn(unused_variables)]` (implied by `#[warn(unused)]`) on by default

Rationale

The new wording ("implied by") better reflects the actual relationship between lint groups and their members
It maintains consistency with messages shown when manually setting lint levels
The change helps users understand the hierarchy of lint settings

Implementation Notes

Only affects messages for default lint levels (not shown when levels are overridden)
External lints remain unchanged (potential discussion point for future changes)

Examples

Case 1: Unchanged behavior when lint level is overridden

#[deny(unused)]
fn main() {
    let x = 5;
}

Result:

note: the lint level is defined here
 --> src/main.rs:1:8
  |
1 | #[deny(unused)]
  |        ^^^^^^
  = note: `#[deny(unused_variables)]` implied by `#[deny(unused)]`

Case 2: Changed behavior for default lint levels

fn main() {
    let x = 5;
}

New output:

= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

Previous output:

= note: `#[warn(unused_variables)]` on by default

Discussion Points

Should we extend this change to external lints as well?
Is "part of" the most accurate terminology?
Doesn't this additional info bloat the message? Perhaps a clippy lint suggesting overriding a whole group instead of a few lints manually would be better

rustbot · 2025-05-08T11:23:57Z

r? @davidtwco

rustbot has assigned @davidtwco.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

rustbot · 2025-05-08T11:23:59Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

karolzwolak · 2025-05-08T19:44:01Z

I'm not satisfied with tests for this change, I tried to add clippy ui test, but I wasn't able to do so, because they use -D warnings option, which triggers different messages. I'd grateful for ideas how to get around this. Similarly, unused group cannot be tested, because of -A unused option is used in ui tests.

karolzwolak · 2025-05-08T20:31:31Z

I gathered my thoughts about possible approaches

Possible Approaches

Option 1: Status Quo (No Change)

Current behavior:

= note: `#[warn(unused_variables)]` on by default

Pros:

Clean and concise
No added complexity

Cons:

Doesn’t inform users about group relationships
Makes bulk configuration harder to discover
Encourages piecemeal overrides

Option 2: Group Annotation (Current PR)

Example:

= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default

Alternatives:

“from group #[warn(unused)]”
“member of #[warn(unused)] group”

Pros:

Adds valuable context with minimal noise
Raises awareness of groupings

Cons:

Terminology might be unclear
Doesn’t offer direct action or suggestions

Option 3: Group Override Lint

Behavior:
Suggests a group-level override when multiple members of the same group are explicitly overridden:

#[allow(unused_variables)]
#[allow(unused_imports)]

Could trigger a suggestion like:

#[allow(unused)]

Pros:

Encourages cleaner, more scalable configs
Helps users write more maintainable code

Cons:

Could result in over-grouping if users suppress more than they intended
Might introduce “suggestion clutter” unless carefully scoped
Needs opt-in/out mechanism to avoid surprising behavior

Option 4: Link to Documentation

Example:

= note: `#[warn(unused_variables)]` on by default
         see https://doc.rust-lang.org/rustc/lints/... for details

Pros:

Keeps messages tidy while enabling deeper exploration
Reuses existing documentation infrastructure

Cons:

Less actionable than inline info
Requires regular doc maintenance to stay accurate

Questions for Discussion

Terminology:
- Which phrasing feels clearest:
  “implied by”, “from group”, “part of”, “member of”?
Configuration Defaults:
- For the group annotation message, should it trigger for external lints?
- For the override lint, what should be the default behavior?
  - Allow-by-default (opt-in)
  - Warn-by-default (opt-out)

karolzwolak · 2025-05-08T20:32:52Z

cc @hkBst
I'd like to hear your thoughts.

Centri3 · 2025-05-08T20:35:38Z

I'm not satisfied with tests for this change, I tried to add clippy ui test, but I wasn't able to do so, because they use -D warnings option, which triggers different messages. I'd grateful for ideas how to get around this. Similarly, unused group cannot be tested, because of -A unused option is used in ui tests.

We already have a few tests that are full workspaces/crates (thus have access to RUSTFLAGS). I see no reason against that unless compiletest overwrites the lint levels we set there.

A better option, if possible, is to have RUSTFLAGS passed by compiletest. There is //@compile-flags which might work, I'm not sure.

Centri3 · 2025-05-08T20:49:03Z

Option 2: Group Annotation (Current PR)

So, about the topic at hand. This current PR feels like it adds a ton of noise for not much benefit tbh, raising awareness for lint groups is -fine- but they aren't really all that commonly needed. Extra noise and confusion just so the user knows about unused is a bit overkill imo.

I was going to suggest the alternative of only doing this when the user specifies deny(unused) or something but it turns out rustc already does this (I knew I recognized this from somewhere). Really, that's the only place I could see there having been potential confusion.

All that said, clippy adding links to documentation everywhere is quite a bit of noise too.

Option 3: Group Override Lint

This will have huge issues in Clippy, whose categories are just for lint levels and aren't really related lints at all. So we do definitely need that opt-out behavior.

This should probably be special cased to unused only—that said, future-incompatible and nonstandard-style seem reasonable enough too

Option 4: Link to Documentation

This is already done for clippy lints and is pretty standard. These are auto-generated and the same can probably be done in rustc as well. Seems reasonable to me considering prior art. It would be nice if there was something like rustc's error codes index to make this a bit more concise, that is perhaps something to look into if you go down this route.

Centri3 · 2025-05-08T20:52:40Z

Option 3: Group Override Lint

sup dawg, I heard you like your linters, so I added a linter for your linter so you can lint your lints while you lint

tests/ui/lint/default-groups-issue-65464.rs

hkBst · 2025-05-09T07:20:08Z

tests/ui/lint/default-groups-issue-65464.rs

+//
+// Ideally, we'd like to use lints that are part of `unused` group as shown in the issue.
+// This is not possible in an ui test, because `unused` lints are enabled with `-A unused`
+// in such tests, and the we're testing a scenario with no modification to the default settings.


Suggested change

// in such tests, and the we're testing a scenario with no modification to the default settings.

// in such tests, and we want to test a scenario with no modification of the default settings.

Do we want that, or are the default settings the only option here? To be honest, I wonder if this test is necessary at all, given the coverage provided by all the existing tests.

Hmm you may be right, the test in current state doesn't actually test anything better than rest of the tests that capture lint output.

hkBst · 2025-05-09T08:28:54Z

Hi @karolzwolak,

I really like your work, and the current PR seems like the most natural option of the proposed alternatives. I think this is a very good way of teaching users about the existence of various lint groups and adds a lot of value to the compiler messages.

Let's consider the following program, which contains all three case of individual lint specified, lint group specified, default lint:

pub fn unused_var() {
    #[warn(unused_variables)]
    let x = 5;
}

pub fn unused() {
    #[warn(unused)]
    let x = 5;
}

pub fn default_() {
    let x = 5;
}

My proposed change from current (stable) output would be:

warning: unused variable: `x`
 --> src/lib.rs:3:9
  |
3 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:2:12
  |
2 |     #[warn(unused_variables)]
  |            ^^^^^^^^^^^^^^^^
+  = note: lint `unused_variables` is part of lint group `unused`

warning: unused variable: `x`
 --> src/lib.rs:8:9
  |
8 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:7:12
  |
7 |     #[warn(unused)]
  |            ^^^^^^
-  = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
+  = note: `#[warn(unused)]` implies `#[warn(unused_variables)]`

warning: unused variable: `x`
  --> src/lib.rs:12:9
   |
12 |     let x = 5;
   |         ^ help: if this is intentional, prefix it with an underscore: `_x`
   |
-   = note: `#[warn(unused_variables)]` on by default
+   = note: default `#[warn(unused)]` implies `#[warn(unused_variables)]`

This last case with "default", assumes that defaults are lint groups instead of individual lints. I'm not sure that is (always) the case. If this is wrong, then perhaps instead just add this line (like for the first function):

+  = note: lint `unused_variables` is part of lint group `unused`

karolzwolak · 2025-05-09T17:29:59Z

This last case with "default", assumes that defaults are lint groups instead of individual lints. I'm not sure that is (always) the case. If this is wrong, then perhaps instead just add this line (like for the first function):
+  = note: lint `unused_variables` is part of lint group `unused`

In my understanding, individual lints are set on default, and the groups are a way to refer to bunch of lints at the same time, but I could be wrong. However I really like the your suggestions for the messages, and perhaps this slight inaccuracy (if I'm right) is okay here, because it makes the messages consistent.

karolzwolak · 2025-05-09T17:35:53Z

My proposed change from current (stable) output would be:

warning: unused variable: `x`
 --> src/lib.rs:3:9
  |
3 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:2:12
  |
2 |     #[warn(unused_variables)]
  |            ^^^^^^^^^^^^^^^^
+  = note: lint `unused_variables` is part of lint group `unused`

warning: unused variable: `x`
 --> src/lib.rs:8:9
  |
8 |     let x = 5;
  |         ^ help: if this is intentional, prefix it with an underscore: `_x`
  |
note: the lint level is defined here
 --> src/lib.rs:7:12
  |
7 |     #[warn(unused)]
  |            ^^^^^^
-  = note: `#[warn(unused_variables)]` implied by `#[warn(unused)]`
+  = note: `#[warn(unused)]` implies `#[warn(unused_variables)]`

warning: unused variable: `x`
  --> src/lib.rs:12:9
   |
12 |     let x = 5;
   |         ^ help: if this is intentional, prefix it with an underscore: `_x`
   |
-   = note: `#[warn(unused_variables)]` on by default
+   = note: default `#[warn(unused)]` implies `#[warn(unused_variables)]`

I think these messages look great, and might be the way to go, since as @Centri3 pointed out, lint wouldn't work too well in this example. @Centri3 thanks for providing feedback, what do you thing about these messages?

EDIT:
What about external lints?
This change would make messages for rustc lints consistent, but that would make them inconsistent with external lints like clippy, unless we'd also change the messages for them. It think I'd be great, but

This will have huge issues in Clippy, whose categories are just for lint levels and aren't really related lints at all.

compiler/rustc_middle/src/lint.rs

compiler/rustc_session/src/session.rs

compiler/rustc_middle/src/lint.rs

tests/ui/lint/default-groups-issue-65464.rs

davidtwco · 2025-07-23T16:02:21Z

Apologies for my delay in getting back to this, it's looking pretty good, could you rebase and I'll do one last pass?

rust-bors · 2025-08-14T22:21:41Z

☀️ Try build successful (CI)
Build commit: 043d1b4 (043d1b4797ddaa3e21301987f831d151e607c06b, parent: be00ea1968d8d5afb5d93d2dedeb97a8bba300cb)

karolzwolak · 2025-08-16T18:15:31Z

@GuillaumeGomez the try build succeeded, can we proceed with merging this? It touches a lot of ui tests, so it stales quickly.

GuillaumeGomez · 2025-08-16T19:08:00Z

@bors r=davidtwco rollup=iffy

bors · 2025-08-16T19:08:03Z

📌 Commit c054b48 has been approved by davidtwco

It is now in the queue for this repository.

…, r=davidtwco Add information about group a lint belongs to # Description Fixes: rust-lang#65464 ## Changes Made - Extended the default lint settings message to include the lint group they belong to - Modified the proposed fix message wording from "part of" to "implied by" for better accuracy - Old message: `` `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default `` - New message: `` `#[warn(unused_variables)]` (implied by `#[warn(unused)]`) on by default `` ## Rationale 1. The new wording ("implied by") better reflects the actual relationship between lint groups and their members 2. It maintains consistency with messages shown when manually setting lint levels 3. The change helps users understand the hierarchy of lint settings ## Implementation Notes - Only affects messages for default lint levels (not shown when levels are overridden) - External lints remain unchanged (potential discussion point for future changes) ## Examples ### Case 1: Unchanged behavior when lint level is overridden ```rust #[deny(unused)] fn main() { let x = 5; } ``` Result: ``` note: the lint level is defined here --> src/main.rs:1:8 | 1 | #[deny(unused)] | ^^^^^^ = note: `#[deny(unused_variables)]` implied by `#[deny(unused)]` ``` ### Case 2: Changed behavior for default lint levels ```rust fn main() { let x = 5; } ``` New output: ``` = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default ``` Previous output: ``` = note: `#[warn(unused_variables)]` on by default ``` ## Discussion Points - Should we extend this change to external lints as well? - Is "part of" the most accurate terminology? - Doesn't this additional info bloat the message? Perhaps a clippy lint suggesting overriding a whole group instead of a few lints manually would be better

Rollup of 10 pull requests Successful merges: - #140794 (Add information about group a lint belongs to) - #144476 (rustdoc-search: search backend with partitioned suffix tree) - #144838 (Fix outdated doc comment) - #145206 (Port `#[custom_mir(..)]` to the new attribute system) - #145208 (Implement declarative (`macro_rules!`) derive macros (RFC 3698)) - #145420 (cg_llvm: Use LLVM-C bindings for `LLVMSetTailCallKind`, `LLVMGetTypeKind`) - #145451 (Add static glibc to the nix dev shell) - #145460 (Speedup `copy_src_dirs` in bootstrap) - #145476 (Fix typo in doc for library/std/src/fs.rs#set_permissions) - #145485 (Fix deprecation attributes on foreign statics) r? `@ghost` `@rustbot` modify labels: rollup

Zalathar · 2025-08-17T04:34:26Z

Failed in rollup: #145517 (comment)

@bors r-

Zalathar · 2025-08-17T04:40:27Z

@bors try jobs=x86_64-gnu-aux

Add information about group a lint belongs to try-job: x86_64-gnu-aux

rust-log-analyzer · 2025-08-17T05:41:13Z

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

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

   |
24 |     let find_head = || (git_repo.head().unwrap().peel_to_commit().unwrap());
   |                        ^                                                  ^
   |
   = note: `#[warn(unused_parens)]` (part of `#[warn(unused)]`) on by default
help: remove these parentheses
   |
24 -     let find_head = || (git_repo.head().unwrap().peel_to_commit().unwrap());
24 +     let find_head = || git_repo.head().unwrap().peel_to_commit().unwrap();
   |

rust-bors · 2025-08-17T05:41:23Z

💔 Test for 0478750 failed: CI. Failed jobs:

try - x86_64-gnu-aux (web logs, extended logs)

karolzwolak · 2025-08-17T08:08:22Z

It looks like the cargo tests are only run for the x86_64-gnu-aux target.
The cargo tests failed because they contain old lint messages.
How do I sync the tests in cargo? We'd have to merge rustc and cargo changes at the same time.

…140794

karolzwolak · 2025-08-17T09:54:04Z

I added a PR that fixes the failing tests in cargo. How do we proceed @davidtwco?

weihanglo · 2025-08-17T12:09:38Z

I added a PR that fixes the failing tests in cargo. How do we proceed?

Yes, we'll need to merge the Cargo PR, and I'll include that in #145478, and wait for the submodule update PR merge, and then this merges.

…140794

…#15849) Needed for [rust-lang/rust#140794](rust-lang/rust#140794) (not merged yet).

Update cargo 28 commits in 840b83a10fb0e039a83f4d70ad032892c287570a..71eb84f21aef43c07580c6aed6f806a6299f5042 2025-07-30 13:59:19 +0000 to 2025-08-17 17:18:56 +0000 - update tests to match lint message changes from #140794 (rust-lang/cargo#15849) - chore: downgrade to [email protected] (rust-lang/cargo#15851) - Reorder `lto` options in profiles.md (rust-lang/cargo#15841) - feat(unstable): add -Zbuild-analysis unstable feature (rust-lang/cargo#15845) - refactor(unstable): group stabilized features (rust-lang/cargo#15846) - Fixes error while running the cargo clippy --all-targets -- -D warning (rust-lang/cargo#15843) - Clarify that `cargo doc --no-deps` is cumulative and won’t delete prev (rust-lang/cargo#15800) - docs: Formatting and cross-linking to build-dir/target-dir docs (rust-lang/cargo#15840) - Stabilize `build.build-dir` (rust-lang/cargo#15833) - make resolve features public for cargo-as-a-library (rust-lang/cargo#15835) - chore(deps): bump slab from 0.4.10 to 0.4.11 (rust-lang/cargo#15832) - chore: remove x86_64-apple-darwin from CI and tests (rust-lang/cargo#15831) - chore(deps): update msrv (3 versions) to v1.87 (rust-lang/cargo#15819) - perf(package): Always reuse the workspace's target-dir (rust-lang/cargo#15783) - More helpful error for invalid cargo-features = [] (rust-lang/cargo#15781) - Add initial integration for `--json=timings` behing `-Zsection-timings` (rust-lang/cargo#15780) - add is_inherited methods to InheritableDependency and InheritableField (rust-lang/cargo#15828) - chore(deps): update compatible (rust-lang/cargo#15804) - docs(unstable): Link out to the Plumbing commands effort (rust-lang/cargo#15821) - chore(deps): update cargo-semver-checks to v0.43.0 (rust-lang/cargo#15825) - test(build-std): relax the thread name assertion (rust-lang/cargo#15822) - chore(deps): update msrv (1 version) to v1.89 (rust-lang/cargo#15815) - Update semver tests for 1.89 (rust-lang/cargo#15816) - Accessing each build script's `OUT_DIR` and in the correct order (rust-lang/cargo#15776) - chore: bump to 0.92.0; update changelog (rust-lang/cargo#15807) - docs: `-Zpackage-workspace` has been stabilized (rust-lang/cargo#15808) - chore(deps): update rust crate cargo_metadata to 0.21.0 (rust-lang/cargo#15795) - docs(build-rs): Fix broken intra-doc links (rust-lang/cargo#15810)

rustbot assigned davidtwco May 8, 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 May 8, 2025

karolzwolak marked this pull request as draft May 8, 2025 11:24

hkBst reviewed May 9, 2025

View reviewed changes

tests/ui/lint/default-groups-issue-65464.rs Outdated Show resolved Hide resolved

hkBst reviewed May 9, 2025

View reviewed changes

davidtwco requested changes May 27, 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 May 27, 2025

This comment has been minimized.

Sign in to view

This comment was marked as resolved.

Sign in to view

karolzwolak force-pushed the allow-unused-doc-65464 branch from bd18376 to 71d486a Compare June 28, 2025 11:48

This comment was marked as resolved.

Sign in to view

karolzwolak force-pushed the allow-unused-doc-65464 branch from 71d486a to 5cce81b Compare July 27, 2025 17:09

rustbot added the T-clippy Relevant to the Clippy team. label Jul 27, 2025

karolzwolak marked this pull request as ready for review July 28, 2025 13:02

rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 28, 2025

bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 16, 2025

Zalathar mentioned this pull request Aug 17, 2025

Rollup of 10 pull requests #145517

Closed

bors 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 Aug 17, 2025

This comment has been minimized.

Sign in to view

rust-bors bot added a commit that referenced this pull request Aug 17, 2025

Auto merge of #140794 - karolzwolak:allow-unused-doc-65464, r=<try>

0478750

Add information about group a lint belongs to try-job: x86_64-gnu-aux

karolzwolak added a commit to karolzwolak/cargo that referenced this pull request Aug 17, 2025

Update tests to match rustc lint message changes from rust-lang/rust#…

2a15e23

…140794

karolzwolak added a commit to karolzwolak/cargo that referenced this pull request Aug 17, 2025

Update tests to match lint message changes from rust-lang/rust#140794

8efac64

karolzwolak added a commit to karolzwolak/cargo that referenced this pull request Aug 17, 2025

update cargo tests to match lint message changes from rust-lang/rust#…

d66dc4f

…140794

karolzwolak mentioned this pull request Aug 17, 2025

update tests to match lint message changes from rust-lang/rust#140794 rust-lang/cargo#15849

Merged

karolzwolak added a commit to karolzwolak/cargo that referenced this pull request Aug 17, 2025

update cargo tests to match lint message changes from rust-lang/rust#…

6bbefbe

…140794

karolzwolak added a commit to karolzwolak/cargo that referenced this pull request Aug 17, 2025

update tests to match lint message changes from rust-lang/rust#140794

fb046a1

github-merge-queue bot pushed a commit to rust-lang/cargo that referenced this pull request Aug 17, 2025

update tests to match lint message changes from rust-lang/rust#140794 (…

71eb84f

…#15849) Needed for [rust-lang/rust#140794](rust-lang/rust#140794) (not merged yet).

weihanglo mentioned this pull request Aug 17, 2025

Update cargo #145478

Open

	// in such tests, and the we're testing a scenario with no modification to the default settings.
	// in such tests, and we want to test a scenario with no modification of the default settings.

Add information about group a lint belongs to #140794

Are you sure you want to change the base?

Add information about group a lint belongs to #140794

Conversation

karolzwolak commented May 8, 2025

Description

Changes Made

Rationale

Implementation Notes

Examples

Case 1: Unchanged behavior when lint level is overridden

Case 2: Changed behavior for default lint levels

Discussion Points

Uh oh!

rustbot commented May 8, 2025

Uh oh!

rustbot commented May 8, 2025

Uh oh!

karolzwolak commented May 8, 2025

Uh oh!

karolzwolak commented May 8, 2025

Possible Approaches

Option 1: Status Quo (No Change)

Option 2: Group Annotation (Current PR)

Option 3: Group Override Lint

Option 4: Link to Documentation

Questions for Discussion

Uh oh!

karolzwolak commented May 8, 2025

Uh oh!

Centri3 commented May 8, 2025

Uh oh!

Centri3 commented May 8, 2025

Uh oh!

Centri3 commented May 8, 2025

Uh oh!

Uh oh!

hkBst May 9, 2025

Choose a reason for hiding this comment

Uh oh!

karolzwolak May 9, 2025

Choose a reason for hiding this comment

Uh oh!

hkBst commented May 9, 2025

Uh oh!

karolzwolak commented May 9, 2025

Uh oh!

karolzwolak commented May 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment was marked as resolved.

This comment was marked as resolved.

davidtwco commented Jul 23, 2025

Uh oh!

rust-bors bot commented Aug 14, 2025

Uh oh!

karolzwolak commented Aug 16, 2025

Uh oh!

GuillaumeGomez commented Aug 16, 2025

Uh oh!

bors commented Aug 16, 2025

Uh oh!

Zalathar commented Aug 17, 2025

Uh oh!

Zalathar commented Aug 17, 2025

Uh oh!

This comment has been minimized.

rust-log-analyzer commented Aug 17, 2025

Uh oh!

rust-bors bot commented Aug 17, 2025

Uh oh!

karolzwolak commented Aug 17, 2025

Uh oh!

karolzwolak commented May 9, 2025 •

edited

Loading