jlxq0/hevy-mcp
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages 1 Wiki Activity Actions

ci: pin the toolchain to 1.98.0 and record the tree's two floors #2

Merged
jlxq0 merged 1 commit from ci/pin-toolchain-and-record-lint-floor into main 2026-08-26 05:29:23 +00:00
Conversation 1 Commits 1 Files changed 5 +69 -9
jlxq0 commented 2026-08-26 05:15:19 +00:00
Owner
Copy link

clippy::unused_async_trait_impl, new in clippy 1.98, fires on methods
#[tool_handler] generates in src/mcp.rs. Nothing written here can be changed
to satisfy it, so it takes an #[allow] with the reason on it. matrix-mcp hit
the same lint from the same macro; this follows what jlxq0/matrix-mcp#112
settled on.

Why the toolchain gets pinned in the same change

An #[allow] naming a lint the running clippy does not have is itself an error
under -D warnings. So the suppression creates a floor, and with
toolchain: stable CI is permanently on the new side of a floor nobody wrote
down — the next clippy release reds an untouched repository and the version
below which nobody can lint is discovered by someone hitting it. ci.yml now
names 1.98.0.

Measured

All four installed toolchains, cargo clippy --all-targets --all-features --locked -- -D warnings, counting distinct sites rather than cargo's
per-target repeats:

clippy before after
1.93.0 3 2
1.96.0 0 1
1.97.1 0 1
1.98.0 1 0

The tree used to lint on 1.96 and 1.97 only, and was red on both sides of that
window. It now lints on 1.98 and later. After, 1.93.0's two are the unknown
lint plus a missing_const_for_fn at src/hevy_client.rs:435 that only 1.93's
clippy fires.

cargo +1.93.0 check --all-features --locked passes, so the build floor is
unmoved: 1.93 builds, 1.98 lints, and those are two different numbers. The
rust:1.93-bookworm builder in the Dockerfile makes the first one a gate rather
than a comment.

The two removed allows

Both duration_suboptimal_units suppressions are gone because the stated reason
was false. src/session.rs said Duration::from_mins was "unstable on our MSRV
(Rust 1.93)". Probed directly on a throwaway crate, in const context:

constructor 1.93.0 1.98.0
from_mins const-stable const-stable
from_hours const-stable const-stable
from_days E0658: duration_constructors E0658

Only from_days is still unstable. Clippy's advice compiled all along, so
SESSION_KEEP_ALIVE is Duration::from_mins(30) and the rate_limit test's
Duration::from_secs(60) is from_mins(1). Values unchanged: 1800s and 60s.
The second allow turned out to be suppressing that single test line on 1.96 and
1.97 and nothing at all on 1.98.

That leaves exactly one attribute setting the lint floor instead of three, and
the one that remains cannot be removed without bumping rmcp.

Verification

  • cargo fmt --all --check clean
  • cargo clippy on 1.93.0 / 1.96.0 / 1.97.1 / 1.98.0 — the table above
  • cargo +1.93.0 check --all-features --locked passes
  • cargo test --all-features --locked — 44 passed, 0 failed
  • cargo deny check bans licenses sources — ok
  • cargo audit still fails: RUSTSEC-2026-0258, h2 0.4.15. That is a
    separate change and this branch does not carry it, so this PR's CI will be red
    on its audit step. Merging this first is deliberate — until the toolchain is
    pinned, every other pull request is red on clippy for a reason that has
    nothing to do with its own diff.

The #[allow] is load-bearing rather than decorative: removing it is the
"before" column's 1.98.0 row, one error.

`clippy::unused_async_trait_impl`, new in clippy 1.98, fires on methods `#[tool_handler]` generates in `src/mcp.rs`. Nothing written here can be changed to satisfy it, so it takes an `#[allow]` with the reason on it. matrix-mcp hit the same lint from the same macro; this follows what `jlxq0/matrix-mcp#112` settled on. ## Why the toolchain gets pinned in the same change An `#[allow]` naming a lint the running clippy does not have is itself an error under `-D warnings`. So the suppression creates a floor, and with `toolchain: stable` CI is permanently on the new side of a floor nobody wrote down — the next clippy release reds an untouched repository and the version below which nobody can lint is discovered by someone hitting it. `ci.yml` now names `1.98.0`. ## Measured All four installed toolchains, `cargo clippy --all-targets --all-features --locked -- -D warnings`, counting distinct sites rather than cargo's per-target repeats: | clippy | before | after | |---|---|---| | 1.93.0 | 3 | 2 | | 1.96.0 | 0 | 1 | | 1.97.1 | 0 | 1 | | 1.98.0 | 1 | 0 | The tree used to lint on 1.96 and 1.97 only, and was red on both sides of that window. It now lints on 1.98 and later. After, 1.93.0's two are the unknown lint plus a `missing_const_for_fn` at `src/hevy_client.rs:435` that only 1.93's clippy fires. `cargo +1.93.0 check --all-features --locked` passes, so the **build** floor is unmoved: 1.93 builds, 1.98 lints, and those are two different numbers. The `rust:1.93-bookworm` builder in the Dockerfile makes the first one a gate rather than a comment. ## The two removed allows Both `duration_suboptimal_units` suppressions are gone because the stated reason was false. `src/session.rs` said `Duration::from_mins` was "unstable on our MSRV (Rust 1.93)". Probed directly on a throwaway crate, in const context: | constructor | 1.93.0 | 1.98.0 | |---|---|---| | `from_mins` | const-stable | const-stable | | `from_hours` | const-stable | const-stable | | `from_days` | `E0658: duration_constructors` | `E0658` | Only `from_days` is still unstable. Clippy's advice compiled all along, so `SESSION_KEEP_ALIVE` is `Duration::from_mins(30)` and the `rate_limit` test's `Duration::from_secs(60)` is `from_mins(1)`. Values unchanged: 1800s and 60s. The second allow turned out to be suppressing that single test line on 1.96 and 1.97 and nothing at all on 1.98. That leaves exactly one attribute setting the lint floor instead of three, and the one that remains cannot be removed without bumping rmcp. ## Verification - `cargo fmt --all --check` clean - `cargo clippy` on 1.93.0 / 1.96.0 / 1.97.1 / 1.98.0 — the table above - `cargo +1.93.0 check --all-features --locked` passes - `cargo test --all-features --locked` — 44 passed, 0 failed - `cargo deny check bans licenses sources` — ok - **`cargo audit` still fails**: RUSTSEC-2026-0258, `h2` 0.4.15. That is a separate change and this branch does not carry it, so this PR's CI will be red on its audit step. Merging this first is deliberate — until the toolchain is pinned, every other pull request is red on clippy for a reason that has nothing to do with its own diff. The `#[allow]` is load-bearing rather than decorative: removing it is the "before" column's 1.98.0 row, one error.
ci: pin the toolchain to 1.98.0 and record the tree's two floors
Some checks failed
CI / cargo (pull_request) Failing after 1m56s
Details
CI / docker (pull_request) Has been skipped
Details
40bde27c61
 
`clippy::unused_async_trait_impl`, new in clippy 1.98, fires on methods
`#[tool_handler]` generates in src/mcp.rs. Nothing here can be rewritten
to satisfy it, so it takes an `#[allow]` with the reason on it. matrix-mcp
hit the same lint from the same macro and resolved it the same way (#112).

The allow is what makes `stable` untenable. An `#[allow]` naming a lint the
running clippy does not have is itself an error under `-D warnings`, so
`toolchain: stable` means CI is always on the new side of a floor nobody
recorded, and the next clippy release reds an untouched repository. `ci.yml`
now names 1.98.0.

Measured today on all four installed toolchains, distinct sites, not
cargo's per-target repeats:

  clippy    before  after
  1.93.0      3       2
  1.96.0      0       1
  1.97.1      0       1
  1.98.0      1       0

The tree used to lint on 1.96 and 1.97 only. It now lints on 1.98 and
later. `cargo +1.93.0 check --all-features --locked` still passes, so the
build floor stays where `rust-version` and the `rust:1.93-bookworm` builder
put it: 1.93 builds, 1.98 lints, two different numbers.

Two `duration_suboptimal_units` allows are removed because their stated
reason was false. src/session.rs claimed `Duration::from_mins` was
"unstable on our MSRV (Rust 1.93)". Probed directly: `from_mins` and
`from_hours` are both const-stable on 1.93.0 and only `from_days` is still
behind `E0658: duration_constructors`, on 1.98.0 as well. Clippy's advice
compiled all along. `SESSION_KEEP_ALIVE` is `from_mins(30)` and the
rate_limit test's `from_secs(60)` is `from_mins(1)`; both values are
unchanged, 1800s and 60s. That leaves exactly one attribute setting the
lint floor rather than three, and the one that remains is the one that
cannot be removed without bumping rmcp.

Not a fix for the red `cargo audit` (RUSTSEC-2026-0258, h2 0.4.15) — that
is a separate change, so this branch's CI will still fail its audit step.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCiHcHN6LrhiuLXbG9SBYG
jlxq0 commented 2026-08-26 05:29:14 +00:00
Author
Owner
Copy link

CI is red as predicted, and it is the audit step.

CI / cargo (pull_request) failed, CI / docker (pull_request) passed. Job logs are not retrievable on this instance — runs/10/jobs/0/logs 404s over both the API and the web path — so this is reproduction rather than log-reading. Ran the job's five steps locally in the workflow's own order, on the toolchain the workflow now pins and with its RUSTFLAGS: -Dwarnings:

fmt      PASS
clippy   PASS
test     PASS
audit    FAIL <- first failing step
deny     PASS

error: 1 vulnerability found! — RUSTSEC-2026-0258, h2 0.4.15. The two steps this PR is about both pass, and the step that fails is the one the next PR fixes.

Merging red on purpose. A reviewer arriving cold sees a red tick, so: the red is a gate this branch deliberately does not carry, stated before the run rather than explained after it. Until the toolchain is pinned, every other pull request in this repo is red on clippy for a reason that has nothing to do with its own diff, which is why this one goes first.

CI is red as predicted, and it is the audit step. `CI / cargo (pull_request)` failed, `CI / docker (pull_request)` passed. Job logs are not retrievable on this instance — `runs/10/jobs/0/logs` 404s over both the API and the web path — so this is reproduction rather than log-reading. Ran the job's five steps locally in the workflow's own order, on the toolchain the workflow now pins and with its `RUSTFLAGS: -Dwarnings`: ``` fmt PASS clippy PASS test PASS audit FAIL <- first failing step deny PASS ``` `error: 1 vulnerability found!` — RUSTSEC-2026-0258, `h2` 0.4.15. The two steps this PR is about both pass, and the step that fails is the one the next PR fixes. Merging red on purpose. A reviewer arriving cold sees a red tick, so: the red is a gate this branch deliberately does not carry, stated before the run rather than explained after it. Until the toolchain is pinned, every other pull request in this repo is red on clippy for a reason that has nothing to do with its own diff, which is why this one goes first.
jlxq0 merged commit 387f9e46bc into main 2026-08-26 05:29:23 +00:00
jlxq0 deleted branch ci/pin-toolchain-and-record-lint-floor 2026-08-26 05:29:24 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
waiting-on-julian
Blocked on Julian. The ask is in the issue.

No labels
waiting-on-julian
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
jlxq0/hevy-mcp!2
No description provided.