Skip to content

deps: async-trait 0.1.92 — clears clippy 1.99 double_must_use blocking every PR - #110

Closed
bkataru wants to merge 1 commit into
mainfrom
fix/clippy-199-double-must-use
Closed

bkataru wants to merge 1 commit into
mainfrom
fix/clippy-199-double-must-use

Conversation

@bkataru

@bkataru bkataru commented Oct 6, 2026

Copy link
Copy Markdown
Member

Every PR is BLOCKED on this check — including #109 and #105

Check & Lint fails on @stable (now clippy 1.99) with double_must_use on four async traits in pawan-core:

agent/backend/mod.rs:18    agent/pool.rs:44
coordinator/mod.rs:444     tools/mod.rs:42

main's last green CI was de893a97 at 2026-10-05 13:03, before stable moved. So this is not anyone's diff — it is toolchain drift that started failing every PR at once, and #109 and #105 are both MERGEABLE/BLOCKED on it.

The lint is generated, not written

The four sites carry no #[must_use]. #[async_trait] 0.1.89's expansion emits one with no message on a function already returning a #[must_use] type. It is a false positive in the macro, so I fixed it at the source instead of suppressing it.

Fix: bump async-trait 0.1.89 → 0.1.92

clippy 1.99, workspace, --all-targets -D warnings    0 errors
clippy 1.98, workspace, --all-targets -D warnings    0 errors

Both toolchains green, so this does not trade one drift for another.

Why the bump and not #[allow(clippy::double_must_use)] on four sites: the allow would need re-justifying as the lint evolves and would hide the diagnostic if it ever fires for a real reason. The bump also picks up the macro's own fixes. syn moves 2.0.117 → 3.0.6 as a new transitive; async-trait 0.1.90 is yanked, 0.1.92 is current.

Scope

Cargo.lock only — 14 insertions, 3 deletions. No source changes.

Landing this should clear the required check for every open PR. #109 carries the actual #108 fix; this is the gate in front of it.



`Check & Lint` fails on every PR because the workflow floats to `@stable`,
which is now clippy 1.99, where `double_must_use` fires on four async traits
in pawan-core:

    agent/backend/mod.rs:18    agent/pool.rs:44
    coordinator/mod.rs:444     tools/mod.rs:42

The lint is generated by `#[async_trait]`: 0.1.89's expansion emits a
`#[must_use]` attribute with no message on a function already returning a
`#[must_use]` type. It is a false positive in the macro, not a defect in
these traits, so it is fixed at the source rather than suppressed.

0.1.92 does not emit it. Measured:

    clippy 1.99, workspace, --all-targets -D warnings   0 errors
    clippy 1.98, workspace, --all-targets -D warnings   0 errors

Chose the bump over `#[allow(clippy::double_must_use)]` on four sites:
the allow would have to be re-justified as the lint evolves, and would
hide the diagnostic if it ever fires for a real reason. The bump also
picks up the macro's own fixes. `syn` moves 2.0.117 -> 3.0.6 as a new
transitive; async-trait 0.1.90 is yanked, 0.1.92 is current.

Unblocks #109 and #105, both currently BLOCKED on this required check.
@bkataru bkataru closed this Oct 6, 2026
@bkataru

bkataru commented Oct 6, 2026 •

Copy link
Copy Markdown
Member Author

Superseded by #94 — closing to keep one canonical copy.

I opened this before checking the queue. #87, #92, #94 and this all carry the
identical Cargo.lock change (async-trait 0.1.89 -> 0.1.92, one file, 14
insertions / 3 deletions), so a fourth is noise rather than progress.

Continuing on #94 (fix(deps): async-trait 0.1.92 for clippy::double_must_use (re-derived, with toolchain control)) — it is the most recent and the one that
already frames the toolchain control.

The one thing this PR measured that the others did not is the differential
across both toolchains; posted on #94 rather than left here.

Branch fix/clippy-199-double-must-use at 8b34a50 is left in place, not deleted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant