mruby-regexp: say at each block why only a byte-indexed subject can answer - #7121

Sorry for the timing on this one: I merged #7120 shortly before this arrived, so master already carries the deletions. That was my doing rather than anything wrong with how you split it.

I compared the two before deciding what to ask for. Sorting the assert lines out of both files and diffing them turns up nothing but two trailing comments, and the number of assertions using a byte-indexed subject is 31 either way. So the substance of this pull request is already in.

What is not in is the part I would still like, which is the writing. Your comments here say, at the point each block asks, why a subject read as UTF-8 has no answer to give; #7120 left that reasoning spread across the blocks in a way that reads less clearly. The ordering differs too, keeping the byte-indexed assertions together rather than interleaved with the ones a whole character answers.

It does not apply as it stands, since the two reworked the same lines. Could you rebase it onto master? Whatever survives as a real diff after that is what I want. If that turns out to be only comments and ordering, that is fine and worth a commit of its own.

One thing worth saying about the series rather than this piece. Landing #7115 and #7116 first is what made these deletions easy to accept: every assertion dropped here already had a counterpart putting the same question to the engine through a subject that can answer it, so I could check that the byte-indexed count came out unchanged rather than read 41 deletions one at a time. Deleting tests is the part of a change that is hardest to review on trust, and building the replacement first is what turned it into a count I could verify.

No actionable comments were generated in the recent review. 🎉

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

Rebased. What survived is the writing and the ordering, and I checked it the
same way you did: sorting the assert lines before and after and diffing them
turns up nothing.

Two things I did not carry over from the version you read.

The first is that it deleted line comments describing assertions that stay.
quantifier on an invalid multibyte literal had five of them, one per
assertion: "x" is not a continuation byte, the quantifier must not be taken
for one either, a sequence cut short emits its bytes one by one. I meant to
drop only the comments describing deleted lines and took these with them. #7120
kept them, so this rebase does too.

The second is a pattern byte that starts no character is a byte in a class,
which I left interleaved. Every byte-indexed assertion there is written next to
the whole character carrying the same byte, and each pair shares one line
comment: an escape names a byte, \u names a codepoint, an invalid leader is a
byte on both sides. Grouping the byte-indexed half at the end left each of those
comments standing over the character half alone. The other three blocks had a
single whole-character assertion sitting among byte-indexed ones with nothing
paired to it, and those moved to the front.

One thing the rebase turned up. Three comments describe a refusal this tree does
not have yet: two say the whole-character subject "goes through as it always
did" and "reaches the engine as it always did", and one says a subject read as
UTF-8 "no longer reaches the engine at all". I wrote them while the refusal was
still one change, and they read as statements about the engine as it is. They
now say what it does today.

And thank you for saying what made the deletions reviewable. I had thought of
#7115 and #7116 as groundwork to get out of the way, but a count you can check
beats 41 lines to read on trust, and that is the better reason to write them
first.