The tree requires clippy >= 1.98 to lint while declaring rust-version 1.93, and nothing records either #112

New issue

Closed

opened 2026-08-25 06:53:06 +00:00 by jlxq0 · 1 comment

jlxq0 commented

2026-08-25 06:53:06 +00:00

Owner

Corrected 2026-08-25. The first version of this issue had the direction of
drift backwards and the fix that followed from it was wrong. See the comment
below for what was wrong; this body is the verified version.

Two #[allow] attributes name lints that only exist from clippy 1.98 onward, so
on any earlier stable they fail as unknown-lints under -D warnings:

clippy::chunks_exact_to_as_chunks at src/mcp.rs:614
clippy::unused_async_trait_impl at src/mcp.rs:7003

Probed directly, with a throwaway crate carrying nothing but the two
attributes:

clippy 0.1.96 (rustc 1.96.0, 2026-05-25): unknown lint, both attributes,
error
clippy 0.1.98 (rustc 1.98.0, 2026-08-18): clean, exit 0

So the tree requires clippy >= 1.98 to lint, and nothing records that. This
is a floor, not a version window: moving forward only adds lints, so the runner
is fine and stays fine as it advances. What goes red is anyone whose stable is
behind 1.98. CI passes because the runner's stable is current.

The CI command and the failing local command are character-for-character
identical, so the command is not the variable. Only the toolchain is.

The sharper half

Cargo.toml:5 declares rust-version = "1.93". The tree cannot pass
cargo clippy -D warnings on anything below 1.98. The declared MSRV is three
releases below what linting actually requires, and these two attributes are what
put it there — the global rule against reaching past the declared
rust-version to satisfy a lint, in the concrete.

Either the MSRV is wrong or the attributes are. Decide which; do not raise
the floor by reflex. chunks_exact_to_as_chunks in particular looks like it may
postdate a rename, so check whether the underlying lint even fires on the code
it guards before keeping the attribute.

Fix

A recorded minimum, or a pinned toolchain: in ci.yml instead of stable.
Not a version range, and not #[allow(unknown_lints)] — that hides the next
instance of the same class.

Acceptance

Not "clippy is green here". State which toolchain the tree is known-good on and
make a mismatch observable, so the next red clippy is classified in one command
rather than an investigation. If the decision is to keep the attributes, the
declared rust-version has to move with them and the build has to fail
honestly below the floor rather than only clippy failing confusingly.

Not the tree's problem, but it is why this surfaced

The machine that hit it had a stale stable: ~/.config/mise/config.toml sets
rust = "stable", mise resolves that through rustup's stable symlink, and
that symlink had not moved since May, so stable was 1.96 with 1.98 sitting
installed alongside. rustup update stable fixes the machine. That is a
separate item and does not change anything above — the tree still declares an
MSRV it cannot lint on.

Provenance

Found by an Operations worker running the release gates for v0.10.2,
direction corrected by Clark by probing both toolchains and reading
rustup toolchain list on the box. The runner's cargo job passed on
153e562 at 02:14Z and 06:52Z throughout, so CI was never evidence either way.

Development work. It must not ride in a release tag.

> **Corrected 2026-08-25.** The first version of this issue had the direction of > drift backwards and the fix that followed from it was wrong. See the comment > below for what was wrong; this body is the verified version. Two `#[allow]` attributes name lints that only exist from clippy 1.98 onward, so on any earlier stable they fail as `unknown-lints` under `-D warnings`: - `clippy::chunks_exact_to_as_chunks` at `src/mcp.rs:614` - `clippy::unused_async_trait_impl` at `src/mcp.rs:7003` Probed directly, with a throwaway crate carrying nothing but the two attributes: - clippy 0.1.96 (rustc 1.96.0, 2026-05-25): unknown lint, both attributes, error - clippy 0.1.98 (rustc 1.98.0, 2026-08-18): clean, exit 0 So **the tree requires clippy >= 1.98 to lint, and nothing records that.** This is a floor, not a version window: moving forward only adds lints, so the runner is fine and stays fine as it advances. What goes red is anyone whose stable is behind 1.98. CI passes because the runner's stable is current. The CI command and the failing local command are character-for-character identical, so the command is not the variable. Only the toolchain is. ## The sharper half `Cargo.toml:5` declares `rust-version = "1.93"`. The tree cannot pass `cargo clippy -D warnings` on anything below 1.98. The declared MSRV is three releases below what linting actually requires, and these two attributes are what put it there — the global rule against reaching past the declared `rust-version` to satisfy a lint, in the concrete. **Either the MSRV is wrong or the attributes are.** Decide which; do not raise the floor by reflex. `chunks_exact_to_as_chunks` in particular looks like it may postdate a rename, so check whether the underlying lint even fires on the code it guards before keeping the attribute. ## Fix A recorded minimum, or a pinned `toolchain:` in `ci.yml` instead of `stable`. Not a version range, and not `#[allow(unknown_lints)]` — that hides the next instance of the same class. ## Acceptance Not "clippy is green here". State which toolchain the tree is known-good on and make a mismatch observable, so the next red clippy is classified in one command rather than an investigation. If the decision is to keep the attributes, the declared `rust-version` has to move with them and the build has to fail honestly below the floor rather than only clippy failing confusingly. ## Not the tree's problem, but it is why this surfaced The machine that hit it had a stale `stable`: `~/.config/mise/config.toml` sets `rust = "stable"`, mise resolves that through rustup's `stable` symlink, and that symlink had not moved since May, so `stable` was 1.96 with 1.98 sitting installed alongside. `rustup update stable` fixes the machine. That is a separate item and does not change anything above — the tree still declares an MSRV it cannot lint on. ## Provenance Found by an Operations worker running the release gates for `v0.10.2`, direction corrected by Clark by probing both toolchains and reading `rustup toolchain list` on the box. The runner's `cargo` job passed on `153e562` at 02:14Z and 06:52Z throughout, so CI was never evidence either way. Development work. It must not ride in a release tag.

jlxq0 changed title from ~~Two #[allow] attributes name lints newer clippy does not have, so the tree only builds on a window of toolchains~~ to The tree requires clippy >= 1.98 to lint while declaring rust-version 1.93, and nothing records either

2026-08-25 06:55:54 +00:00

jlxq0 commented

2026-08-25 06:56:10 +00:00

Author

Owner

Recording what the first version of this issue got wrong, because the fix that
followed from it was the wrong fix and somebody may have read it.

Claimed: the failing machine's stable was ahead of the runner's, so the
tree builds only on a window of clippy versions, and the runner drifting forward
would eventually red a tree nobody touched.

Actual: both lints are new in 1.98 and absent from 1.96. The failing
machine's stable was three months behind the runner's. There is no window and
no forward-drift risk: moving forward only adds lints. The requirement is a
floor.

Why the wrong version was plausible: a red clippy locally and a green clippy in
CI is consistent with either direction, and the direction cannot be inferred
from that pair. It took probing both toolchains against the two attributes in
isolation, plus rustup toolchain list on the machine, to tell which way it ran.
Neither the CI logs nor the failure message distinguishes them — the same
unknown-lints error appears whichever side lacks the lint.

The rust-version = "1.93" conflict in the body was only found while chasing the
cause, and it is the larger of the two problems.

Recording what the first version of this issue got wrong, because the fix that followed from it was the wrong fix and somebody may have read it. **Claimed:** the failing machine's stable was *ahead* of the runner's, so the tree builds only on a window of clippy versions, and the runner drifting forward would eventually red a tree nobody touched. **Actual:** both lints are new in 1.98 and absent from 1.96. The failing machine's stable was three months *behind* the runner's. There is no window and no forward-drift risk: moving forward only adds lints. The requirement is a floor. Why the wrong version was plausible: a red clippy locally and a green clippy in CI is consistent with either direction, and the direction cannot be inferred from that pair. It took probing both toolchains against the two attributes in isolation, plus `rustup toolchain list` on the machine, to tell which way it ran. Neither the CI logs nor the failure message distinguishes them — the same `unknown-lints` error appears whichever side lacks the lint. The `rust-version = "1.93"` conflict in the body was only found while chasing the cause, and it is the larger of the two problems.

jlxq0 referenced this issue

2026-08-25 06:57:24 +00:00

feat(channel): let the mount open an attachment, not just name it #113

jlxq0 referenced this issue from a pull request that will close it,

2026-08-25 07:11:26 +00:00

build: pin CI to 1.98.0 and write down why the tree cannot lint below it #114

jlxq0 referenced this issue

2026-08-25 07:13:44 +00:00

feat(channel): relay permission prompts through Matrix #115

jlxq0 closed this issue

2026-08-25 07:25:52 +00:00

jlxq0 referenced this issue