I realized later that the tests didn't cover two cases related character ranges in icase mode:

• A non-collating range that triggers the small range optimization (right bound - left bound < 4 after translation).
• A non-collating range that triggers neither the small range optimization nor the bitmap optimization.

For the idempotent translation functions used in the test, this means we need code points with values >= 0x200 for the lower-case variants, so I had to make use of wide strings for the two additional tests.

@muellerj2
The number of <regex> bug fixes you've introduced for the last few months is a bit shocking.
Is <regex> really that buggy, how did it even functionate?🤐
Anyway, good job and thanks for making the STL better for all of us.

Is really that buggy, how did it even functionate?🤐

That's relatively easy to say: Most of the fixed bugs are or were specific to some subclasses of regexes (rarely used syntax options, specific escapes, wregex with specific character classes, usage of collating elements, icase or collate mode etc.), so if your regex wasn't in any of these subclasses, you weren't affected.

The bug fixed by this PR, for example, would only be observed if the traits classed provided (a) a non-trivial (or worse a non-idempotent) translate() function or (b) a non-idempotent translate_nocase() function. I'm not aware of any code that defined such translation functions. Well, except for the test code in this PR, but translation functions in the test code are deliberately weird to catch that they aren't applied exactly once. They aren't designed to do anything useful.

Thanks! 😻 I pushed cosmetic changes.

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

Thanks for fixing this bug, obscure though it may be! 🐞 🕵️ 😻