Repository navigation
id: clippy-lint red on main — expect_used at src/tags.rs:1484,1499 (clippy 1.99) #2401
Description
Problem
The basic: nix flake check (clippy-lint) PR check fails on pkgs/id with two clippy::expect_used errors in code this repo has not changed:
error: used `expect()` on an `Option` value
--> src/tags.rs:1484:22
|
1484 | let ch = input[i..].chars().next().expect("i is a char boundary");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
= note: requested on the command line with `-D clippy::expect-used`
error: used `expect()` on an `Option` value
--> src/tags.rs:1499:22
|
1499 | let ch = input[i..].chars().next().expect("i is a char boundary");
Evidence it is pre-existing, not PR-local
- Observed on PR id(world): wire manifest apply — module install + schedules over the wire (#807) #1820 (
queue/2661-807-apply-wiring), run 40894646360 job 123626426997 — the failure was first misread as nix-cache throttling (HTTP 418 on a different, earlier attempt); the rerun reached clippy and produced these two real errors. pkgs/id/src/tags.rsis not in PR id(world): wire manifest apply — module install + schedules over the wire (#807) #1820's file list (13 files changed, none insrc/tags.rs).- The same two
expect()calls are present verbatim inorigin/main:pkgs/id/src/tags.rsat the same lines, so the check should be red for any PR that touchespkgs/id.
Impact
Every PR touching pkgs/id is unmergeable: clippy-lint is a required check. #1820 is parked on this, and other app/id work will queue behind it.
Expected fix
Either replace the two expect() calls with a non-panicking form, e.g.
let Some(ch) = input[i..].chars().next() else { break };(the enclosing loops already break when i >= input.len()), or, if the panic is genuinely intended as an invariant, #[allow(clippy::expect_used)] with a comment — but prefer the let-else, since i is always advanced by len_utf8.
Verify with the clippy-lint check (nix build .#checks.<system>.id-clippy-lint or cargo clippy -p id --all-targets -- -D clippy::expect-used), not just cargo check: the 366 warnings in the same log are non-fatal and must not be "fixed" here.
Related
- id(world): wire manifest apply — module install + schedules over the wire (#807) #1820 (blocked on this)
- id: F12.1 apply wiring — module install + schedules reconciliation #807 (F12.1 apply wiring, the parent)
Acceptance criteria
basic: nix flake check (clippy-lint)passes on main with noclippy::expect_usederrors atpkgs/id/src/tags.rs:1484,1499— fixed in place or via the keystone PR id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 fmt/clippy change set, not both.- No behaviour change to the char-boundary parsing those lines implement; existing pkgs/id tests pass in CI.
Activity
developing-today commentedon Oct 29, 2026
CODE-1224
dezren39 commentedon Oct 30, 2026
Intake review (fleet monitor, 2026-10-29 run):
expect()calls are verbatim on main. Looks SOLVED-IN-FLIGHT: lane reports describe keystone PR id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 as carrying the fmt/clippy family fix — but PR id: rustfmt meta_client.rs + drop expect() in tags parser — unbreak main fmt/clippy (#2151) #2335 is OPEN (CLEAN) and blocked by the merge-queue stall ci: merge queue ejects every PR — no merge since #2233 (10:57Z), entries dropped 2-6 min into AWAITING_CHECKS #2403, and main (5a34fa7) still contains both lines, so this issue stays open; do not close until clippy-lint is green on main.dezren39 commentedon Nov 3, 2026
Triage findings (queue task 3611, repo-worker-code lane bf419306, 2026-11-03):
Already resolved — recommending close. Verified against fresh
origin/main(d368b9fb):src/tags.rs:1484,1499,.expect("i is a char boundary")onchars().next()) are gone from main. The file now lives atpkgs/id/src/tags.rsand both sites use panic-freelet Some(ch) = input[i..].chars().next() else { break; }with an invariant comment.git grep -n '.expect(' origin/main -- pkgs/id/src/tags.rsreturns zero matches — no.expect(call remains in the file, so-D clippy::expect-usedcannot fire on it.pkgs/id/src/tags.rs+9/-3), merged 2026-10-30 (merge commit9c976b8).Caveat: could not confirm a green clippy-lint run on current main because the
idworkflow queue is backlogged (latest main runs allqueued), and the oldbasic: nix flake check (clippy-lint)job name no longer exists under current workflow names. But the lint in question is deterministic on file content — with no.expect(left in the file, this exact failure cannot recur. If clippy flags anything else inpkgs/id, that would be a new issue, not this one.No follow-up fix packet needed. Closing with evidence per the triage acceptance criteria.
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
expect_usedfailure; revalidate main and route.