mruby-regexp: support the atomic group (?>...) - #7256

An atomic group commits to the first match of its body: once the body has
matched, what follows may fail the group as a whole but cannot make the body
give text back or take another branch. The parser refused the form, so a
pattern that uses it to keep a quantifier from backtracking could not be
compiled:

/(?>a+)ab/ =~ "aaab"   # CRuby: nil
                       # mruby: RegexpError, undefined (?...) sequence
/(?>a|ab)c/ =~ "abc"   # CRuby: nil
/(?>a)+b/ =~ "aab"     # CRuby: 0

Compiling the group

The compiler brackets the body with two zero-width instructions, RE_ATOMIC
and RE_ATOMIC_END. Both carry the group's nesting depth, 1 for an outermost
group, which is how the executor pairs the end of a body with the group it
closes when the groups nest. The parser counts the depth in atomic_depth
while it is inside the body, and the group forces the backtracking engine,
since the Pike VM has no way to cut a thread. Both zero-width walkers in the
compiler step over the two instructions, and compute_fixed_len() still
rejects them, so an atomic group is not accepted inside a lookbehind, as in
Onigmo.

The cut

bt_match() now answers one of four things instead of a bool. BT_MATCH and
BT_FAIL are the two it had. The third, BT_CUT(depth), is what an
RE_ATOMIC_END answers when the text after it fails: the frames between that
end and the RE_ATOMIC that opened the group hand it up unchanged, so none of
the RE_SPLITs inside the body get to try their other branch, and the frame
that ran the RE_ATOMIC turns it into BT_FAIL, which its caller backtracks
over the way it would any other failed atom. RE_SAVE undoes its capture for
a cut as for a failure, since the group the cut fails may be the one the slot
was written inside. A cut never escapes a lookaround, because the RE_ATOMIC
that absorbs it is inside the sub-pattern too.

The depth is what makes nested and sequential groups come out right. In
/(?>a(?>b|bc)|abcd)d/, a d failing after the outer group is a cut of
depth 1: it passes through the inner group's end and start unchanged, and the
| in the outer body may not try abcd. In /(?>x(?>a)(?>b)y)/, the two
inner groups have the same depth 2, and each cut is absorbed by the
RE_ATOMIC frame nearest to it, which is its own.

The fourth answer, BT_LIMIT, is what a frame answers when it gives up at
the recursion or step limit. A frame that gets it hands it up; a RE_SPLIT
takes it as that branch failing and answers with its other branch, as it
would with a failure. What no frame does is turn it into a cut, or into a
lookaround's answer, since a limit says nothing about the text. That matters
because the recursion limit is what stops a repetition whose body can match
empty under this engine, and the repetition being stopped may be inside the
group's body, where a cut would keep its exit from being taken:

/(?>(?:b*)+)/ =~ ""     # CRuby: 0

The four lookarounds hand a limit up for the same reason: read as "no match",
it would make a negative assertion hold. In practice the RE_SPLIT nearest
the limit answers with its exit branch and the limit rarely reaches the
sub-pattern's frame at all, so no differential run told the two apart; the
rule is there so that no frame invents an answer.

The README lists the group and names it among the constructs that pick the
backtracking engine, alongside the lookbehinds it had left out.

Size

.text of bin/mruby, build_config/ci/gcc-clang.rb, each side from a clean
build directory. re_compile.o and re_exec.o are the objects that change;
in bintest they account for +528 and +1,104 of the delta.

Verification

The tests go in regexp_syntax.rb beside the other group forms. They cover
the cut against a plain group, a repeated atomic group giving back whole
iterations, nested and sequential groups at the same depth, the recursion
limit reached inside the body, captures kept and unset, the cut staying inside
a lookaround, options ending with the body, to_s round-tripping and
free-spacing, and the three rejected forms.

Differential against CRuby 4.0.6. Random patterns over a, b, c,
., [ab], plain, non-capturing and atomic groups, alternation and all the
quantifiers including the lazy and interval forms, nested up to four deep,
each with at least one atomic group, run with match against 30 subjects and
compared as MatchData#to_a:

The 294 lines with lookaround captures and backreferences are each a capture
written inside a lookaround or a backreference to the group that contains it,
two things this engine already answers differently from Onigmo; at 288 of
them, master gives the same answer as here for the pattern with its atomic
groups made plain. The 480 lines with quantifiers anywhere are repetitions
whose body can match empty: this engine has no empty-iteration stop and runs
such a repetition to the recursion limit, on master as here, and at 373 of
the 480, master's answer for the pattern with the atomic groups made plain
differs from CRuby as well.

rake test, build_config/ci/gcc-clang.rb, no compiler warning:

The default configuration: 2,125 total, 0 KO, 0 crash, plus its 112 bintests.

Environment

# ci/gcc-clang bintest
gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRB_GC_FIXED_ARENA -DMRBGEM_MRUBY_REGEXP_VERSION=0.0.0 -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -DMRB_USE_DEBUG_HOOK -I"include" -I"mrbgems/mruby-regexp/include" -I"build/bintest/include" -o "build/bintest/mrbgems/mruby-regexp/src/re_exec.o" "mrbgems/mruby-regexp/src/re_exec.c"

# ci/gcc-clang full-debug
gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -g3 -O0 -DMRB_GC_STRESS -DMRB_USE_DEBUG_HOOK -DMRBGEM_MRUBY_REGEXP_VERSION=0.0.0 -DMRB_DEBUG -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -I"include" -I"mrbgems/mruby-regexp/include" -I"build/full-debug/include" -o "build/full-debug/mrbgems/mruby-regexp/src/re_exec.o" "mrbgems/mruby-regexp/src/re_exec.c"

# ci/gcc-clang cxx_abi
gcc -MMD -c -g -O3 -Wall -Wundef -Wwrite-strings -x c++ -std=gnu++03 -DMRB_GC_FIXED_ARENA -DMRBGEM_MRUBY_REGEXP_VERSION=0.0.0 -DMRB_USE_CXX_EXCEPTION -DMRB_USE_CXX_ABI -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -I"include" -I"mrbgems/mruby-regexp/include" -I"build/cxx_abi/include" -o "build/cxx_abi/mrbgems/mruby-regexp/src/re_exec.o" "mrbgems/mruby-regexp/src/re_exec.c"

# ci/gcc-clang byte-string
gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRBGEM_MRUBY_REGEXP_VERSION=0.0.0 -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -I"include" -I"mrbgems/mruby-regexp/include" -I"build/byte-string/include" -o "build/byte-string/mrbgems/mruby-regexp/src/re_exec.o" "mrbgems/mruby-regexp/src/re_exec.c"

# ci/gcc-clang ascii-case
gcc -MMD -c -std=gnu99 -g -O3 -Wall -Wundef -Werror-implicit-function-declaration -Wwrite-strings -DMRB_USE_ASCII_CASE -DMRBGEM_MRUBY_REGEXP_VERSION=0.0.0 -DMRB_USE_BIGINT -DMRB_USE_COMPLEX -DHAVE_MRUBY_ENCODING_GEM -DMRB_UTF8_STRING -DHAVE_MRUBY_IO_GEM -DMRB_USE_RATIONAL -DHAVE_MRUBY_REGEXP_GEM -DMRB_USE_SET -DMRB_USE_TASK_SCHEDULER -I"include" -I"mrbgems/mruby-regexp/include" -I"build/ascii-case/include" -o "build/ascii-case/mrbgems/mruby-regexp/src/re_exec.o" "mrbgems/mruby-regexp/src/re_exec.c"

Summary by CodeRabbit

• New Features

  • Added support for atomic groups using (?>...) in regular expressions.
  • Atomic groups now prevent backtracking into completed group matches, enabling more precise matching behavior.
  • Patterns using atomic groups automatically use the compatible backtracking engine.

• Bug Fixes

  • Improved handling of nested groups, captures, lookarounds, repetition, and empty matches involving atomic groups.
  • Invalid atomic-group syntax now raises RegexpError consistently.

• Documentation

  • Documented atomic-group syntax and engine-selection behavior.