refactor loop

loops over inclusive (a..=b) ranges are known to cause issues in LLVM. Here the impact is especially large,

Benchmark 2 (416 runs): target/relwithdebinfo/examples/compress rs 1 tests/input/quick/sample3.ref
  measurement          mean ± σ            min … max           outliers         delta
  wall_time          12.0ms ±  236us    11.6ms … 15.8ms         23 ( 6%)        ⚡-  5.2% ±  0.3%
  peak_rss           3.20MB ± 68.7KB    3.01MB … 3.28MB          0 ( 0%)          +  0.1% ±  0.3%
  cpu_cycles         47.7M  ±  937K     46.5M  … 64.1M          17 ( 4%)        ⚡-  5.7% ±  0.2%
  instructions        215M  ±  313       215M  …  215M           5 ( 1%)        ⚡-  6.3% ±  0.0%
  cache_references   4.63M  ±  107K     4.24M  … 5.10M           8 ( 2%)          +  0.5% ±  0.3%
  cache_misses        253K  ± 31.8K      109K  …  362K           7 ( 2%)        ⚡-  9.4% ±  1.7%
  branch_misses      82.7K  ±  385      82.2K  … 89.1K          29 ( 7%)          -  0.6% ±  0.1%

Author: folkertdev

libbz2-rs-sys/src/blocksort.rs

@@ -338,10 +338,10 @@ fn fallbackSort(
 
                 /*-- scan bucket and generate header bits-- */
                 let mut cc = -1;
-                for i in l..=r {
-                    let cc1 = arr2.eclass()[fmap[i as usize] as usize] as i32;
+                for (i, x) in fmap[l as usize..=r as usize].iter().enumerate() {
+                    let cc1 = arr2.eclass()[*x as usize] as i32;
                     if cc != cc1 {
-                        SET_BH!(i);
+                        SET_BH!(l + i as i32);
                         cc = cc1;
                     }
                 }