mruby-regexp: read a pattern the way the build reads a String - #7161

MRB_UTF8_SCAN let mruby-regexp reach core's UTF-8 scan by defining a macro
from its mrbgem.rake, so a gem decided how core compiled. Nothing else in
the tree asks for the scan. This retires the macro and puts the whole of a
build on one side: where MRB_UTF8_STRING is defined the engine reads
characters, and where it is not it reads bytes, pattern included.

What changes for a build without MRB_UTF8_STRING

The engine already read a binary subject one byte per character. This puts the
pattern and every other string there on the same side:

/./.match("あ")[0].bytesize   # 3 before, 1 now
/Ā/                           # one atom before, two atoms of one byte each now
/Ā/i                          # RegexpError before, ASCII folding now
"あいう".gsub(/./) { "x" }    # "xxx" before, "xxxxxxxxx" now
[\u{3042}]                    # held the character before, holds its bytes now

The last one follows from the second. A class member is one character, so a
character above ASCII in a class is the bytes that spell it, and [Ā] answers
for either of them rather than for the pair. A \u escape naming the same
character comes to the same members.

That is what CRuby answers for a string it reads as bytes:

s = "\xE3\x81\x82".dup.force_encoding("ASCII-8BIT")
s =~ /./n
$~[0].bytesize    # => 1

So the build that indexes its Strings by byte stops being the one build where
String#length counts bytes and a Regexp counts characters.

How

Core answers what a run of bytes spells, rather than the gem asking for a
scan it then has to guard:

static inline mrb_int
mrb_enc_charlen(const char *p, const char *e)
{
#ifdef MRB_UTF8_STRING
  return mrb_utf8len(p, e);
#else
  (void)p; (void)e;
  return 1;
#endif
}

mrb_enc_char_head() and mrb_enc_decode() are the same shape. They sit
outside the MRB_UTF8_STRING block the way mrb_str_char_len() and
mrb_str_valid_encoding_p() already do, so the gem carries no #ifdef of its
own and a second codec would be a change in one place rather than in every
caller. They are inline because a matcher asks them once per byte: out of line
the byte build carries 3,320 bytes of text more and the build with
mruby-encoding 2,016.

The spelling of a codepoint has no such neutral answer and stays UTF-8, so
\u{...} names the same bytes on either build.

Four commits:

1. mruby-regexp: read a pattern through the engine's character helpers. The
   executor already asked through mrb_re_charlen() and
   mrb_re_decode_char(); the compiler asked core directly, so one question
   had two spellings. No behavior change.
2. string.c: keep the UTF-8 scan behind MRB_UTF8_STRING alone. The macro
   goes, mrb_enc_* arrives, and the gem reads through it.
3. mruby-regexp: fold a named codepoint only where it is read back whole. A
   bug the second commit exposes: \u{e9} under /i compiled to a class, and
   a class compares one decoded character, so where the build decodes bytes it
   answered for a lone 0xE9 byte and never for the character the escape
   names. Adding /i stopped the pattern matching what it named. It now takes
   the fold only where the spelling reads back as the one character it spells.
4. mruby-regexp: name in a class what spelling it out names. The class path
   had the same gap and the tests did not reach it: [\u{3042}] compiled to a
   member the matcher never produces on a byte build, so it matched nothing at
   all, silently, with or without /i, while [あ] written out held the bytes
   and answered. Found by review on this PR.

Size

The byte-string build of ci/gcc-clang, x86_64-linux, gcc 13.3.0, text
segment, master 31bc19bf2 on the left.

Without MRB_UTF8_STRING:

src/string.o      37072 ->  36032   -1040
re_compile.o      22657 ->  22577     -80
re_exec.o         15442 ->  13537   -1905
re_utf8.o           198 ->    198       0
regexp.o          18005 ->  17621    -384
                                   ------
                                    -3409

With MRB_UTF8_STRING, the same five come to -16 bytes, so the reading a
build already does costs it nothing.

Tests

MRUBY_CONFIG=ci/gcc-clang rake -m test, all four builds and the bintests,
KO 0 and Crash 0:

byte-string   Total 2240   Skip 46
full-debug    Total 2303   Skip 3
bintest       Total 2304   Skip 11   + 117 bintests
cxx_abi       Total 2304   Skip 11

byte-string skips 17 more than master's 29. Those are the assertions that put a
question a byte build no longer takes: a subject read as UTF-8, or a pattern
spelling a character in more than one byte. Two of them say what they expect
of a byte build instead rather than skip, String#split with an empty pattern
and the character class overflow guard, since both still hold something there.

What this reverses

MRB_UTF8_SCAN is two days old. 56a55f56d added it so the gem could drop a
UTF-8 decoder of its own and call core's, which 47836c20d had just put
behind MRB_UTF8_STRING. Retiring the macro is small.

The property the macro was added to preserve is not. mruby-regexp has read a
pattern as UTF-8 on every build since 1cfa153ff created the gem, first
through that decoder of its own, and 56a55f56d kept it deliberately: "the
engine reads UTF-8 whatever a build's strings index by, and the default gembox
already builds it that way".

So the question here is not whether a two day old macro should go. It is
whether reading a pattern as UTF-8 is right for a build whose Strings are
bytes, which has held since March and has been carried forward rather than
weighed on its own.

What a class comes to here

A character class is a set of single characters, and on a build whose
characters are single bytes a character above ASCII is not one of them. It
becomes the bytes that spell it, so a class answers for each of them on its
own:

/[Ā]/.match?("Ā")        # true
/[Ā]/.match?("\xC4".b)   # true, and Ā is not what that is

That is the byte reading of a class applied evenly, and read_class_atom()
already does it for any character it decodes in one byte. What changes here is
how often that happens: on master only a byte that starts no character reaches
it, and on a byte build every non-ASCII character does.

The way out of it is to keep the class holding characters and compile it down
to the byte sequences that spell them, so [Ā] answers for Ā alone. I built
that to find out what it costs, and the measurements are in this gist.
The answer is not size: the lowering costs 3,136 bytes of text on the byte
build, which is most of what the table above removes, so the two come out
level. It is these three.

• Lowering a class needs the pattern read as UTF-8. Grouping \xC4 \x80 into
  one member cannot be justified from the bytes, so the gem takes back the
  decoder 56a55f56d removed and the build stops reading its pattern the way
  it reads a String, which is the whole of what this PR is for.
• Lowering only the positive form is cheap and wrong: with the negated form
  left as it is, [^Ā] matches Ā, the class accepting the character it was
  written to reject.
• Lowering the negated form means complementing over characters first, which
  turns [^a] and \W from one instruction into 43, costs 2.5x to 3.9x on
  the matches that use them, grows a compiled Regexp from 1,484 bytes to
  4,948, and stops [^a] matching a byte that spells no character. On a build
  whose reason to exist is binary data, that last one is backwards.

Gating the lowering to a class that names a character it cannot hold keeps the
speed and keeps the bytes, at 496 bytes of text. But then [^a] answers over
bytes while [^Ā] answers over characters, which is this PR's split moved from
the positive form to the negated one rather than closed.

So a class over-matches on a byte build, and I take that as the price of a
build reading one way throughout, rather than as a reason to have it read its
pattern one way and its subject another.

The decision this needs

Whether a build whose Strings index by byte should read its patterns the same
way. Everything above follows from that one answer, including the class.

If it should, this is ready to leave draft. If a class holding whole characters
matters more than a build reading one way throughout, then what master does is
the price of it and I will close this instead.

Not in this PR

MRB_REGEXP_UNICODE_CASE and re_cased.h stay as they are. With the fourth
commit in, no pattern reaches their refusal on a byte build any more, which
makes them dead weight there, but tying the case data to what the engine reads
is a separate question and a separate change.

Summary by CodeRabbit

• New Features

  • Regular expressions now support encoding-aware matching in both UTF-8 and byte-oriented builds.
  • Unicode escapes and character classes behave consistently with the active string encoding.
  • String splitting and character indexing reflect UTF-8 characters or individual bytes as appropriate.

• Bug Fixes

  • Improved matching boundaries, lookbehind behavior, case folding, and handling of multibyte or malformed characters.

• Documentation

  • Updated regexp documentation to clarify encoding-dependent matching behavior and examples.