Skip to content

fix: lazy quantifiers matched greedily (#175) - #181

Open
Arthur031221 wants to merge 1 commit into
coregx:mainfrom
Arthur031221:bugfix/issue-175-lazy-quantifier
Open

Arthur031221 wants to merge 1 commit into
coregx:mainfrom
Arthur031221:bugfix/issue-175-lazy-quantifier

Conversation

@Arthur031221

Copy link
Copy Markdown

Covers the cases in #175 that go through the char class and composite searchers, building on the ones @kolkov posted there (the first five rows of the new test).

The char class searcher and the composite searcher scan greedily, so they ignored lazy quantifiers. \d+? on "11" returned [0 2] where the stdlib returns [0 1] [1 2], and \w+?\s??\w? on "1A\nc" returned [0 4] where the stdlib returns [0 2] [3 4]. Patterns with a lazy quantifier now skip those two searchers. That's slower on those paths: \d+? over 100 KB goes from about 75 to 371 microseconds.

Two related cases aren't fixed here. The submatch of (\d+?) on "11" is still [0 2 0 2] because the OnePass DFA never stops at a lazy match. .*?a on "xaax" still returns [0 3] because the reverse suffix search takes .*? for .*.

Added TestIssue175_LazyQuantifier, run with go test ./....

Assisted by Claude/Codex.

Co-authored-by: Andrey Kolkov 3740898+kolkov@users.noreply.github.com

@Arthur031221
Arthur031221 requested a review from kolkov as a code owner October 9, 2026 14:33
The char class searcher and the composite searcher scan greedily, so
`\d+?` on "11" returned [0 2] instead of [0 1]. Patterns with a lazy
quantifier now use another strategy there.

Co-authored-by: Andrey Kolkov <3740898+kolkov@users.noreply.github.com>
@Arthur031221
Arthur031221 force-pushed the bugfix/issue-175-lazy-quantifier branch from a730b81 to 562dac8 Compare October 9, 2026 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant