{{ message }}
<regex>: Remove match mode _Skip_zero_length#6262
Merged
StephanTLavavej merged 7 commits intoApr 29, 2026
Merged
Conversation
muellerj2
commented
Apr 18, 2026
…llowed by natural cleanup
StephanTLavavej
approved these changes
Apr 22, 2026
Member
Member
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.

This removes a strange internal match mode
_Skip_zero_length. Its only purpose was to shift the start of the pattern search one position later, but to setprefix().firstin thematch_resultsobject as if there were no such shift. This match mode was only used to implement the increment operator ofregex_iterator.Moreover,
_Regex_search2has an additional parameter_Orgwhich is only used to set the member_Orgin thematch_resultsobject.This PR removes this internal match mode
_Skip_zero_lengthand replaces it inregex_iteratorby using another internal match mode,_Match_not_null. This sometimes reduces the number of constructed matcher objects in the zero-length match case, which can improve performance by avoiding some unnecessary allocations. But the fusion of tworegex_searchcalls means that the implementation deviates a bit further from the specification in [re.regiter.incr]: This necessitates some additional logic to emulate thematch_prev_availupdate to the match flags, because the original spec allows the caller to differentiate in some cases whether the first or the second call toregex_search()succeeded when incrementing from an initial zero-length match. The new tests make sure that this alternate logic behaves like the spec. (We do not have to emulate this logic strictly if the regex search fails, because the value of the match flags member is irrelevant for the end-of-sequence iterator.)Moreover, this PR moves the update of the
match_resultsfield_Orgoutside_Regex_search2/3. Instead, the callers have to set this member correctly now. This allows the removal of the_Orgparameter from_Regex_search2/3. Note that the callers were already responsible for choosing the value of_Org; they just didn't assign it themselves, but instead passed it to_Regex_searchwhich performed the assignment (and did nothing else with this argument).Drive-by change:
_STD-qualify a few more calls.Drive-by bugfix: I think
regex_iterator::operator++()failed to call_Adopt(nullptr)in debug mode in one case when no more match was found.