[ksshonda]

Summary

When regex.next() fails in find_select_next (e.g. ICU hits its time limit on catastrophic backtracking), the regex was left where the failed search stopped, while next_search_offset already pointed at the start of the search. The next search with the same offset skipped regex.reset(), resumed from the stale position, wrapped around and re-selected the first match instead of failing again.

With (a+)+b on ab + 40 × a + c ab, repeated forward searches alternated between an error and a "successful" re-selection of the first match.

Changes

• Add find_regex_next, which resets the regex to next_search_offset when next() fails, and use it for both next() calls in find_select_next.
• Use the same helper in find_select_prev. It replaces the equivalent recovery added in Merge upstream microsoft/edit (up to b7f8322) #5, so both directions now share one code path.
• Add test_find_next_error_retries_from_same_position.

This also exists in upstream's find_select_next. A report for upstream has been drafted separately and has not been submitted yet.

Testing

• cargo test: all tests pass. With find_regex_next reverted to a plain next(), both test_find_next_error_retries_from_same_position and test_find_prev_error_keeps_forward_position fail.
• cargo clippy --all-targets: no warnings
• cargo fmt --check: clean

🤖 Generated with Claude Code