From 02c5ad9839ed5e516a4c2ca463515eb8423ee1d7 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Tue, 4 Aug 2026 20:01:37 -0500 Subject: [PATCH] fix(installer): satisfy clippy's unnecessary_sort_by on the CI toolchain The two descending sorts in the applier used an explicit comparator. CI runs clippy 1.97, where `unnecessary_sort_by` flags that and `-D warnings` turns it into a build failure; the local toolchain here is 1.94, which does not have the lint. `sort_by_key` with `Reverse` says the same thing. Co-Authored-By: Claude --- src/patch.rs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/patch.rs b/src/patch.rs index a2ffec5..4d1c96c 100644 --- a/src/patch.rs +++ b/src/patch.rs @@ -259,7 +259,7 @@ pub fn resolve(file: &FilePatch, content: &[u8]) -> Resolution { } // Highest offset first, so applying one edit never invalidates the next one's range. - edits.sort_by(|a, b| b.start.cmp(&a.start)); + edits.sort_by_key(|e| std::cmp::Reverse(e.start)); Resolution::Applicable { rung: if stock { Rung::StockHash @@ -369,7 +369,7 @@ pub fn apply(content: &[u8], edits: &[Edit]) -> Vec { // The edits arrive highest-offset-first from `resolve`, so each splice leaves every remaining // range valid. Re-sorting here rather than trusting the caller keeps that a local property. let mut ordered: Vec<&Edit> = edits.iter().collect(); - ordered.sort_by(|a, b| b.start.cmp(&a.start)); + ordered.sort_by_key(|e| std::cmp::Reverse(e.start)); for edit in ordered { out.splice(edit.start..edit.end, edit.replacement.iter().copied()); }