Repository navigation
Conversation
#86. With lane 3's measurement as the starting point, and the open question it flagged answered by source inspection rather than by a build. WHAT LANE 3 ESTABLISHED (accepted, with one correction) - The lint is new in the 1.99 stable line: 1.95.0 exit 0, 1.98.0 exit 0, 1.99.0 exit 101 with 4 errors. - Four sites, all bare `#[async_trait] pub trait`. Confirmed on origin/main (de893a9), not just a working branch: backend/mod.rs:19 LlmBackend, pool.rs:45 PoolExecutor, coordinator/mod.rs:445 TaskRunner, tools/mod.rs:43 Tool. (The line numbers in the handoff point at the attribute; the trait is the following line.) - `grep -rn must_use --include='*.rs' crates/pawan-core/src/` returns 0 — there is no signature here to change, so "remove the redundant #[must_use]" targets code that does not exist in this repo. THE OPEN QUESTION: does a fixed async_trait exist? Yes. 0.1.89 src/expand.rs:69 method.attrs.push(parse_quote!(#[must_use])); 0.1.92 no `must_use` anywhere in the crate; the same site now pushes lint_suppress_with_body() / lint_suppress_without_body() (expand.rs:72,74,104,114), and tests/ui/must-use.rs still exercises the path. So the attribute was deliberately removed, not relocated, and a patch bump fixes this at source. That makes an `#[allow]` unnecessary — the remedy that would suppress a real redundancy pawan did not author is not needed. RISK, stated rather than glossed: this is not a pure patch bump in effect. async-trait 0.1.92 depends on syn 3, so the resolution also adds syn 3.0.6; the lock now carries syn 1.0.109, 2.0.117 and 3.0.6 side by side. That is a major-version change to a proc-macro dependency riding along with a patch bump, and it deserves review on its own merits rather than being waved through as "just a lockfile bump". NOT VERIFIED HERE, deliberately: this host is CPU-starved (load ~45 on 8 cores), so I did not run `cargo clippy --workspace -- -D warnings` on 1.99 to confirm the lint clears. The acceptance test is that command going green on 1.99.0; the argument above is source inspection, not a measurement of it. Toolchain pinning (lane 3's remedy 1) is left to the owner: it is a policy choice between 1.94/1.98/1.99 that affects CI for everyone, and this change fixes the lint on 1.99 without needing the pin.
Withdrawing — this is a duplicate of #87, #92 and #94I opened this without running All four are the same one-file
Do not merge this. Pick a survivor among #87/#92/#94; I have no basis to claim mine is What I am not withdrawing: the evidence on pawan#86 that the bump fixes the lint at source Closing this PR rather than leaving it open to compete. |
Answering a lane's open question by source inspection: a fixed async-trait exists, so no
#[allow]is needed.a lane handed this over because I hold the lock. Their two gaps, both closed below.
Gap 2 (the cheap one, and it decides the remedy): a fixed async-trait exists
The attribute was removed, not relocated, and a UI test still covers the behaviour. So remedy (2)
works at source and subsumes (3): an
#[allow]would suppress a redundancy pawan did not author, andit is not needed.
async-trait = "0.1"in the workspace manifest, so 0.1.92 is semver-legal.Gap 1: the four sites confirmed on origin/main, not just a working branch
de893a9, traits on the line after the attribute:(The handoff's line numbers point at
#[async_trait]; the trait is one line below.)The risk, stated rather than glossed
This is not a pure patch bump in effect. async-trait 0.1.92 depends on syn 3, so the resolution
also adds
syn 3.0.6, and the lock now carries syn 1.0.109, 2.0.117 and 3.0.6 side by side. Amajor-version change to a proc-macro dependency riding along with a patch bump deserves review on its
own merits, not a wave-through as "just a lockfile change". If that is unacceptable, the alternative
is the pin.
Not verified here, deliberately
This host is CPU-starved (load ~45 on 8 cores), so I did not run
cargo clippy --workspace -- -D warningson 1.99 to confirm the lint clears. The acceptance test isexactly that command going green on 1.99.0 — my argument is source inspection, not a measurement of
it, and the two should not be confused.
CI cannot settle it either: pawan is on hosted runners and hosted jobs are refused at admission.
Left to the owner
Toolchain pinning (a lane's remedy 1) is a policy choice between 1.94/1.98/1.99 affecting CI for
everyone, so I have not made it. This PR removes the need for it by making the code lint-clean on
1.99, but the pin is still worth having for the reason a lane gives: without it, "main is red" is
undefined, because it depends on which stable the runner picks.
No code was changed and no
#[allow]added — the lockfile is the entire diff.