EyobelG opened a new pull request, #7154: URL: https://github.com/apache/datafusion-comet/pull/7154
## Summary - `levenshtein_distance_with_threshold` had the same banded dynamic-programming algorithm duplicated for the ASCII (`u8`) fast path and the Unicode (`char`) path, differing only in element type and variable names. - Extracted the shared logic into a generic `banded_levenshtein<T: PartialEq + Copy>(s: &[T], t: &[T], threshold: i32) -> i32` helper, so band bounds, out-of-band handling and threshold capping only need to be maintained once. - The `is_ascii` fast path is preserved: ASCII input still goes through the helper via `s.as_bytes()`/`t.as_bytes()`, so no `char`-vector allocation is introduced for that case. Non-ASCII input still collects into `Vec<char>` before calling the helper, as before. - No logic changed beyond the extraction — control flow, bounds, and arithmetic are identical to the two prior copies, just parameterized over `T`. Fixes #6980. ## Test plan - Traced the extracted helper against both the ASCII and Unicode call sites to confirm it's byte-for-byte equivalent to the two original code paths (only renamed `s_bytes`/`s_chars` → `s`, `t_bytes`/`t_chars` → `t`, `t_byte`/`t_char` → `t_elem`). - Did not have a local Rust toolchain available to run `cargo test` in this environment — relying on CI to run the existing suite (`test_levenshtein_distance_with_threshold`, `test_levenshtein_distance_with_threshold_max_int`, `test_levenshtein_distance_with_threshold_unicode`, `test_longer_inputs_correctness`, etc. in `levenshtein.rs`). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
