[bkataru]

Independent re-measurement of #86 on current main — same fix, re-derived, with a toolchain control

a lane (cross-repo). This re-derives the diagnosis rather than inheriting it. I did not claim this row: the coordinator claim dirmacs/pawan#86 was refused — already claimed by a lane. That claim's local lock is 25h old, past its window, but a live lock file is a holder until released, so I worked around nothing and verified read-only in an isolated clone.

The state, as of now

origin/main @ de893a9 is red, and I reproduced it rather than reading it off CI:

$ RUSTUP_TOOLCHAIN=1.99.0 cargo clippy --workspace -- -D warnings
  error: this function has a `#[must_use]` attribute with no message,
         but returns a type already considered as `#[must_use]`
  ... ×4
  error: could not compile `pawan-core` (lib) due to 4 previous errors
  exit 101

All four, and nothing else:

crates/pawan-core/src/agent/backend/mod.rs:18:15
crates/pawan-core/src/agent/pool.rs:44:28
crates/pawan-core/src/coordinator/mod.rs:444:15
crates/pawan-core/src/tools/mod.rs:42:15

Toolchain pinned in-invocation, per the estate context — this host's ambient RUSTUP_TOOLCHAIN is 1.95.0, and 1.95's clippy does not carry this lint, which is why the failure looks unreproducible to anything relying on the ambient value.

Is it a new lint, or new code? The control settles it

toolchain	tree	exit	double_must_use
1.98.0	main @ de893a9	0	0
1.99.0	main @ de893a9	101	4

Same tree, same command, only the toolchain differs. The code did not change; the lint is new. The four sites were last touched by fd2580c/ba8d000 (v0.5.0 work), long before the 1.99 clippy release. So the title's framing is right for once, and main went red with no commit to point at.

Root cause: upstream macro expansion, not pawan

$ grep -rn '#\[must_use' crates/ --include='*.rs' | wc -l
0

There is no #[must_use] anywhere in pawan's source. async-trait 0.1.89 pushes one onto every function it generates (expand.rs: method.attrs.push(parse_quote!(#[must_use]))); those return Pin<Box<dyn Future>>, and both Pin and Box are already #[must_use]. All four sites are #[async_trait] expansions — I checked each.

This is why a blanket #[allow(clippy::double_must_use)] would be wrong: it would suppress a genuine upstream defect at four call sites while leaving the same macro output wrong everywhere else it appears. No #[allow] is added in this diff — 0 sites.

Both arms, CI's exact flags

$ RUSTUP_TOOLCHAIN=1.99.0 cargo clippy --workspace -- -D warnings

  arm                async-trait   exit   sites
  baseline (main)        0.1.89     101     4
  treatment (this)       0.1.92       0     0

Same tree, same toolchain, same flags; only the macro version differs. The exit-code flip is load-bearing — a warning-level run exits 0 while printing all four sites, which would let a broken merge through. Cargo.lock only, 1 file, +14 −3.

Relation to #87

#87 (fix/async-trait-092-double-must-use, OPEN) already carries this exact fix and already says Fixes #86. I did not need to open a second one. This PR is a re-derivation from current main with an added 1.98-vs-1.99 control that #87 does not have, and it should be treated as duplicate-and-superseded — closing it in favour of #87 is the tidier outcome and I have no basis to claim otherwise.

The larger gap, unchanged

main pins no toolchain: no rust-toolchain.toml, and CI uses floating dtolnay/rust-toolchain@stable. That is what turns a clippy release into an unexplained red on an unchanged tree, and it will happen again. Pinning it (or passing toolchain: to the action) is the durable fix. That decision is separate and is the owner's.

Read-only apart from this branch: nothing merged, main untouched.

[bkataru]

Toolchain differential for this bump — measured on both toolchains

Adding evidence rather than a fourth copy of the lockfile diff. The question a
reviewer has to answer for this bump is "does it trade one drift for another?",
and that needs both toolchains, not just @stable.

Measured on this branch, workspace-wide, --all-targets -- -D warnings:

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

So the bump clears double_must_use on the toolchain that started failing it
and does not introduce anything on the pinned one.

The lint is generated, not written. None of the four sites
(agent/backend/mod.rs:18, agent/pool.rs:44, coordinator/mod.rs:444,
tools/mod.rs:42) carries a #[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, which is why the bump is the right fix
rather than #[allow(clippy::double_must_use)] on four sites — an allow would
need re-justifying as the lint evolves and would hide the diagnostic if it ever
fired for a real reason.

Independent confirmation: Check & Lint went from failure to success,
11 steps executed on the identical lockfile change at 8b34a508.

Note the residual failure is a different check — Security Audit / cargo audit
fails on main and on every branch (main's last green was de893a9 at
2026-10-05 13:03, before stable moved). Not caused by this bump, but it will
block the required-check set until someone takes it.

[bkataru]

Reviewed — recommend merge to clear the double_must_use red wall.

What it is: lockfile-only change (Cargo.lock, 1 file). async-trait 0.1.89 -> 0.1.92.

Why it clears the gate: the clippy::double_must_use failure on every open PR is macro-generated — async-trait 0.1.89's expansion emits a #[must_use] with no message on a fn returning an already-#[must_use] type, and -D warnings + clippy 1.99 promote it to a hard error. 0.1.92 stops the macro emitting that attribute, so the lint clears at the source. Verified: this PR's Check & Lint PASSES while the same gate is red on #105/#112/#113/#114/#115.

Scope check: introduces syn 3.0.6 alongside existing syn 1.0.109 / 2.0.117 (a 3-way split). This is the normal consequence of the async-trait bump — syn major versions coexist without issue in Cargo. No source files touched.

Note: its only failing check is cargo audit, a separate pre-existing RUSTSEC matter unrelated to the lint. That should not block this merge (the audit findings exist on main too).

This is preferable to pinning the toolchain (which would freeze pawan off the rust 1.99 migration) or adding #[allow(double_must_use)] (which would hide the diagnostic if it ever fired for a real reason). #87 and #92 are the same bump — merge one, close the other two as duplicates.