chore(lint): clear the two clippy failures on a current toolchain #489

Merged

longjacksonle merged 1 commit from chore/clippy-current-toolchain into main

2026-08-06 21:57:13 +02:00

longjacksonle commented

2026-08-06 21:54:04 +02:00

Owner

Two mechanical lint fixes, no behaviour change. Flagged on #485, #486, #487 and #488 and split out rather than smuggled into a feature branch.

Why now

just check-clippy fails on unmodified main with a clippy newer than the one CI currently runs. CI is green today only because of that version gap, so the repo is one runner upgrade away from a red Check that has nothing to do with whatever change is under review. That is the kind of failure people learn to wave through, which is worth avoiding on a gate that exists to be believed.

The changes

src/pages/projects.rs (manual_div_ceil). The explicit if total_tasks > 0 guard becomes checked_div, which returns None on a zero divisor and therefore gives the same "no tasks means no progress" answer.

// before
let progress = if total_tasks > 0 { (completed_tasks * 100 / total_tasks) as u32 } else { 0 };
// after
let progress = (completed_tasks * 100).checked_div(total_tasks).unwrap_or(0) as u32;

src/pages/time.rs (unnecessary_sort_by). sort_by(|a, b| a.at.cmp(&b.at)) becomes sort_by_key(|e| e.at). at is a DateTime<Utc>, which is Copy, so there is no clone, and both sorts are stable, so the comment directly above about equal timestamps keeping insertion order still holds.

Verification

cargo clippy --all-targets -- -D warnings now passes cleanly, which it did not before this branch. Plus cargo check --target wasm32-unknown-unknown, cargo fmt --all --check, cargo test (261 passed, 0 failed), and both guard scripts.

Two mechanical lint fixes, no behaviour change. Flagged on #485, #486, #487 and #488 and split out rather than smuggled into a feature branch. ## Why now `just check-clippy` fails on unmodified `main` with a clippy newer than the one CI currently runs. CI is green today only because of that version gap, so the repo is one runner upgrade away from a red Check that has nothing to do with whatever change is under review. That is the kind of failure people learn to wave through, which is worth avoiding on a gate that exists to be believed. ## The changes **`src/pages/projects.rs` (`manual_div_ceil`).** The explicit `if total_tasks > 0` guard becomes `checked_div`, which returns None on a zero divisor and therefore gives the same "no tasks means no progress" answer. ```rust // before let progress = if total_tasks > 0 { (completed_tasks * 100 / total_tasks) as u32 } else { 0 }; // after let progress = (completed_tasks * 100).checked_div(total_tasks).unwrap_or(0) as u32; ``` **`src/pages/time.rs` (`unnecessary_sort_by`).** `sort_by(|a, b| a.at.cmp(&b.at))` becomes `sort_by_key(|e| e.at)`. `at` is a `DateTime<Utc>`, which is `Copy`, so there is no clone, and both sorts are stable, so the comment directly above about equal timestamps keeping insertion order still holds. ## Verification `cargo clippy --all-targets -- -D warnings` now passes cleanly, which it did not before this branch. Plus `cargo check --target wasm32-unknown-unknown`, `cargo fmt --all --check`, `cargo test` (261 passed, 0 failed), and both guard scripts.

longjacksonle added 1 commit

2026-08-06 21:54:04 +02:00

chore(lint): clear the two clippy failures on a current toolchain

Check / fmt + clippy + tests (pull_request) Successful in 3m8s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

76addd08aa

`just check-clippy` fails on unmodified main with a clippy newer than the one CI runs, so the repo is one runner upgrade away from a red Check that has nothing to do with the change under review. Both are mechanical and neither alters behaviour.

`manual_div_ceil` in projects.rs: the explicit `if total_tasks > 0` guard becomes `checked_div`, which yields None on a zero divisor and so gives the same "no tasks means no progress" answer.

`unnecessary_sort_by` in time.rs: `sort_by(|a, b| a.at.cmp(&b.at))` becomes `sort_by_key(|e| e.at)`. `at` is a `DateTime<Utc>`, which is Copy, and both sorts are stable, so the comment above it about equal timestamps keeping insertion order still holds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011myibMMwyb6za3GVWJGkiX

longjacksonle scheduled this pull request to auto merge when all checks succeed

2026-08-06 21:54:30 +02:00