automata: make behavior more consistent when WhichCaptures::None
is used
#1303
+86
−7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Specifically, when used with
meta::Regex
. Before this PR, if callersbuilt a
meta::Regex
withWhichCaptures::None
, then it was possiblefor
find
to sometimes returnSome
and sometimes returnNone
,just based on the sequence of previous search calls.
In particular, when
WhichCaptures::None
is used, some regex engines(like the
PikeVM
) cannot report match offsets while some (like thelazy DFA) can. This meant that if the meta regex engine happened to
select the lazy DFA for a
Regex::find
call, then it would returnSome
. But if it happened to select the Pike VM, then it would returnNone
. Since engine selection can be influenced by the haystack itself,this leads to the behavior of
find
being tied to the contents of thehaystack.
Instead, what we should do is make it so anything that returns match
offsets on a
meta::Regex
will always returnNone
whenWhichCaptures::None
is used, even ifRegex::is_match
returnstrue
.(Yes, this is a weird option and it's crazy that
Regex::is_match
canreturn
true
whileRegex::find
can returnNone
. This was alreadytrue before this PR and is a result of a very low level option that
optimizes for memory usage in specific circumstances. This sort of
whacky behavior can't be observed in the
regex
crate API. Only inregex-automata
.)