fix: handle character boundary in search mode #18928
Conversation
rustbot
added
the
S-waiting-on-review
|
There is another slicing that looks like it may panic in line 305 ( But do you know why it panics? We use |
| @@ -320,7 +320,7 @@ impl SearchMode { | |||
| }; | |||
| match m { | |||
| Some((index, _)) => { | |||
| name = &name[index + 1..]; | |||
| name = &name[ceil_char_boundary(name, index + 1)..]; | |||
There was a problem hiding this comment.
Given we want to discard the string up to (and including, hence the + 1) the query_char, I think we can just do
let mut chars = name[index..].chars();
chars.next();
chars.as_str()instead?
There was a problem hiding this comment.
Or
name = name[index..].strip_prefix(|_: char| true).unwrap_or_default()
We panic because we slice one byte after the character, so if the character is multi byte we slice into it instead of beyond it.
That one shouldn't cause issues, given the searcher in that mode does a prefix search and so the prefix should match fully (it would be a bug if not) |
But it might not match. |
|
Then we shouldn't even reach that far, the fst automaton should only give us prefix matches, the only thing that can differ at that point is the ascii casing which will not cause issues here. (if we were doing general casing changes it might) |
fix #18918
I also used Clippy to scan and check usages of slicing in the project, and found that only here could cause a panic.