Repository navigation
Description
Problem
nix flake check's clippy-lint check fails on current main for the id crate, blocking the aggregate flake check on every PR (observed on PR #1838, a docs-only change to pkgs/id/TODO.md, run 40775308431, job 123141230630, 2026-10-28T23:31Z):
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");
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");
error: could not compile `id` (lib) due to 2 previous errors
The code is on main today (introduced by #1743, commit 35726e8: parse_search_query in pkgs/id/src/tags.rs), and the crate denies clippy::expect-used on the command line (-D clippy::expect-used), so this is a hard error, not one of the ~150 tracked warnings in #803.
Fix
Replace both expect("i is a char boundary") calls with a non-panicking boundary step (e.g. let Some(ch) = ... else { break }), preserving the parser's behavior — i is maintained as a char boundary by construction, so the None arm is unreachable in practice but must not panic.
Acceptance
clippy-lintflake check passes on main.parse_search_querybehavior unchanged (existing tags/search tests pass).
Acceptance criteria
- The
clippy-lintflake check passes onmain(bothexpect()sites inparse_search_query,pkgs/id/src/tags.rs, replaced with non-panicking char-boundary handling). parse_search_querybehaviour is unchanged: the existing tags/search tests pass in CI.- The work is delivered via a branch + PR (no direct push to main); verification runs in GitHub Actions CI, not on the sandbox.
- Evidence (CI links or check output) is recorded on this issue before it is closed.
Activity
developing-today commentedon Oct 29, 2026
CODE-929
dezren39 commentedon Oct 29, 2026
Intake review
-D clippy::expect-usederror on main. No open or merged PR fixingtags.rsclippy was found at intake (checked open PRs and recent main commits at 2026-10-29T00:3xZ).expect("i is a char boundary")calls with alet Some(ch) = ... else { break }step). Becauseclippy-lintis part of the aggregate flake check, every PR currently inherits this failure — hence priority/high despite the xs size.Nonearm is unreachable by construction (iis maintained as a char boundary); the replacement must not change parser behaviour on malformed input.clippy-lintis green.🤖 Agent note · state: filed
developing-today commentedon Nov 3, 2026
agent-note:v1
state: reviewed (coverage loop-back)
Coverage pass 2026-11-03, loop-back review: this issue was re-reviewed (drift / overlap / already-handled / stale / blockers / ordering) so every open issue in the four repos is reviewed and in the system. Verdict: still live; in the system as task 7257 (triage, queued, priority 50) in repo-health-code-pilot. Labels audited and synced. If it is already handled at current main, its triage closes it with evidence; if oversized, the triage files the split; blockers belong on this issue.
Found via: coverage loop-back 2026-11-03
dezren39 commentedon Nov 3, 2026
🤖 Agent note · picked up
dezren39 commentedon Nov 3, 2026
🤖 Agent note · done
6f00e7e00(2026-10-29, "id: rustfmt meta_client.rs and drop expect() in tags search parser (id: pkgs/id/src/meta_client.rs is not rustfmt-clean on main — every PR inherits three failing fmt checks #2151)") replaced bothinput[i..].chars().next().expect("i is a char boundary")sites inpkgs/id/src/tags.rswith the exact non-panicking form this issue prescribes:let Some(ch) = ... else { break };— verified from the commit diff.main(9380bf6)pkgs/id/src/tags.rs:grep 'expect('returns zero hits in the whole file;parse_search_querykeeps the char-boundary invariant comment and the let-else guards at both former sites.expect()remaining in the crate file, the-D clippy::expect-usedfailure mode named here cannot recur from these sites; parser behavior was unchanged by the fix (same control flow,Nonearm unreachable by construction, nowbreak).already_done.