Rust hygiene: 29 expect_in_hot_path findings across bots/* #255
Copy link
Copy link
Open
Labels
priority:p2Normal - queue itNormal - queue itscope:repoConfined to this repositoryConfined to this repositorystatus:readyFully specified and ready to be picked upFully specified and ready to be picked uptech-debtKnown shortcut, drift, or hygiene owed - includes cleanupKnown shortcut, drift, or hygiene owed - includes cleanup
Description
Summary
Hypatia scan on PR #249 surfaced 29 expect_in_hot_path findings (medium severity) across bots/* Rust analyzers. Out of scope for the workflow-hygiene PR (#254) since this is per-bot code review.
Affected modules (top of list)
bots/accessibilitybot/src/analyzers/alt_text.rs
bots/accessibilitybot/src/analyzers/aria.rs
bots/accessibilitybot/src/analyzers/contrast.rs
bots/accessibilitybot/src/analyzers/css.rs
bots/accessibilitybot/src/analyzers/forms.rs
bots/accessibilitybot/src/analyzers/keyboard.rs
bots/accessibilitybot/src/analyzers/language.rs
bots/accessibilitybot/src/analyzers/media.rs
bots/accessibilitybot/src/analyzers/semantic.rs
bots/cipherbot/src/analyzers/config.rs
(20+ more — see full scan output at gitbot-fleet#249.)
Recommended remediation
For each .expect("...") in a hot path:
- If the error is genuinely impossible: rewrite with
unwrap_unchecked()+ safety comment, OR refactor to make the impossibility type-level. - If the error is recoverable: migrate to
?propagation. - If panic is desired but message could be richer: use
.unwrap_or_else(|e| panic!("context: {}", e)).
Per the estate's fix-unwrap-to-match.sh recipe + the rust scanner hygiene rules in hypatia's CLAUDE.md.
Test plan
-
cargo clippy --workspace -- -W clippy::expect_usedbaseline before/after. - Hypatia scan finding count drops by 29 after fix.
Related
- gitbot-fleet#249 (where surfaced)
- gitbot-fleet#254 (workflow-hygiene fix PR)
Metadata
Metadata
Assignees
Labels
priority:p2Normal - queue itNormal - queue itscope:repoConfined to this repositoryConfined to this repositorystatus:readyFully specified and ready to be picked upFully specified and ready to be picked uptech-debtKnown shortcut, drift, or hygiene owed - includes cleanupKnown shortcut, drift, or hygiene owed - includes cleanup
Activity
hyperpolymath commentedon Jun 20, 2026
Grounded against
main(f39d3d5), post sustainabot→oikosbot extraction (#297)Re-checked after #297/#298 emptied the
bots/sustainabot/slot — this issue survived the extraction and is still valid. The two named targets (accessibilitybot,cipherbot) are untouched; onlysustainabot's vendored crates were removed, so the count is now ≤29 (a few of the unenumerated "20+ more" may have lived in the extracted crates).What the findings actually are
In
accessibilitybot/src/analyzers/*the.expect()calls are overwhelmingly on compile-time-constant selectors/regexes, re-parsed on every call:The error is genuinely impossible (the input is a string literal), but the scanner flags it because it sits in a per-document / per-file hot path.
Recommended fix shape (two birds, one stone)
Hoist each constant
Selector::parse/Regex::newinto aLazyLock(std, 1.80+) oronce_cell::sync::Lazystatic:This (a) removes the
.expect()from the hot path per remediation option 1, and (b) stops recompiling the same selector/regex on every invocation — a perf win as well as the hygiene fix. The one remaining.expect()runs once at first use on a literal, which is the estate-sanctioned "impossible error" form.Note for whoever picks this up
Do it from a fresh clone at current
main, and verify withcargo clippy --workspace -- -W clippy::expect_usedper the test plan. (A pre-#297 clone would re-vendor the now-deleted sustainabot files if pushed, so start clean.)Generated by Claude Code