ci: Rust Lint job breaks on Rust 1.92, blocking a toolchain bump past the pinned 1.91.1

[mehmetkr-31]

Summary

The Rust Lint CI job will fail as soon as rust-toolchain.toml is bumped past the pinned 1.91.1. On Rust 1.92, the command the job runs already fails on arc-consensus-types.

Reproduction

With a 1.92 toolchain, running the exact ci.yml lint command:

$ cargo clippy --all-targets --all-features -- -D warnings
error: unused import: `crate::codec::impl_versioned_codec`
  --> crates/types/src/codec/network.rs:26:5
error: unused import: `crate::codec::impl_versioned_codec`
  --> crates/types/src/codec/wal.rs:22:5
error: could not compile `arc-consensus-types` (lib) due to 2 previous errors

main is green today only because of the toolchain pin. Because the job runs with -D warnings, these are hard failures rather than warnings, so the toolchain bump is blocked until they are addressed.

Cause

impl_versioned_codec is a macro_rules! macro defined in crates/types/src/codec/mod.rs above the pub mod network; and pub mod wal; declarations. Textual macro scoping already puts it in scope for both child modules, so use crate::codec::impl_versioned_codec; in each of them never resolved to anything the module did not already have. Rust 1.92 is the first release whose unused_imports lint reports this.

Removing the two imports leaves the pub(crate) use impl_versioned_codec; re-export in codec/mod.rs with no remaining users, so it warns in turn — nothing outside the codec module refers to the macro by path.

Suggested fix

Delete the two use lines and the now-unused re-export: 4 lines, no behaviour change, since textual macro scoping is long-stable and resolves identically on both toolchains.

The alternative, if you would rather not touch the imports, is an #[allow(unused_imports)] — but carrying an allow for lines that do nothing seemed worse than deleting them.

Opened as #232. I do not have 1.91.1 available locally to verify there, so CI on this repo's pinned toolchain is the real check; if the macro somehow failed to resolve without the import, the build would fail loudly rather than silently.

[osr21]

Confirmed against the repo while reviewing the fix — PR #232 resolves this and I've approved it there (verified the textual-scoping claim: the macro at codec/mod.rs:29 precedes the pub mod declarations, so the imports were always redundant; my one ask on the PR is a comment making that ordering dependence visible, since the removal makes mod.rs declaration order load-bearing).

Two points worth adding to the issue record itself:

1. The pin + -D warnings combination is working as designed, and this issue is the process functioning — worth saying explicitly so nobody "fixes" the wrong thing. -D warnings on an unpinned toolchain means CI breaks spontaneously the day a new Rust ships a smarter lint, with no code change to blame. The rust-toolchain.toml pin at 1.91.1 is exactly what converts that from a surprise outage into a controlled event: new lints only bite when someone deliberately bumps the pin, with a PR to hang the fixes on. So the right takeaway isn't "-D warnings is fragile" — it's that toolchain bumps should be expected to carry small lint-fix payloads like #232, cleared ahead of the bump exactly as done here.

2. There's a cheap early-warning system for this class. This issue was only discoverable by someone happening to run a newer toolchain locally. A scheduled (weekly cron, continue-on-error: true, non-blocking) CI job running the same cargo clippy --all-targets --all-features -- -D warnings on beta would surface every future 1.9x lint change ~6 weeks before it can block a toolchain bump — turning "someone trips over it locally" into "the repo files its own #234s on schedule." Since actions-rust-lang/setup-rust-toolchain honors an explicit toolchain: input over the repo pin, it's a ~10-line additional job in ci.yml reusing the existing cache key. That's the standard pattern for repos that pin + deny, and it composes with (not replaces) the pin.

With #232 merged, the 1.92 path is clear as far as this lint goes — though anyone executing the actual bump should expect the possibility of other new-in-1.92 lints in crates this issue didn't audit, since the reproduction here stopped at the first compile failure (arc-consensus-types fails the workspace build early, so downstream crates were never linted under 1.92). A full cargo clippy run on 1.92 after applying #232 is the cheap way to confirm the bump is actually unblocked rather than one-error-deep.