Support non-ascii case folding within i modifier #90
Conversation
| 'pattern': '(?i:[є-ґ])', | ||
| 'options': { modifiers: 'transform' }, | ||
| 'matches': ['\u0462', '\u0463', '\u1C87'], | ||
| 'expected': '(?:[\\u0404-\\u040F\\u0454-\\u0491\\u1C87])', |
There was a problem hiding this comment.
Here U+1C87 ᲇ should be matched because the uppercase of U+1C87 is U+0462 Ѣ, well in range of [є-ґ], while the lowercase of U+0462 Ѣ is U+0463 ѣ. So the String#toLowerCase approach in #80 will miss cases like that, which is why we have introduced iu-mappings.
| 'expected': '(?:[Kk\\u212A])', | ||
| }, | ||
| { | ||
| 'pattern': '(?i:\\u2C2F)', |
There was a problem hiding this comment.
This is also an example that a legacy ES5 engine might not support all case foldings in the Basic Plane, because the U+2C2F is introduced in Unicode 14.
| // https://mths.be/es6#sec-runtime-semantics-canonicalize-abstract-operation | ||
| ( | ||
| if( |
There was a problem hiding this comment.
Nit: there is some weird formatting going on here
There was a problem hiding this comment.
(✔️ I have completed forgotten the context so I can give a review)
The idea of this PR is to further extend current iu-mappings to the BMP characters (U+0080 - U+FFFF) because we have to handle the i modifier, as we generate a non-i flag regex and simulate the i behaviour in modified groups. While the approach in #80 works for most common characters, it will introduce platform-depending behaviours because old platform will not support new Unicode characters.
JLHwung
force-pushed
the
support-non-ascii-case-folding-i-modifier
branch
from
17d07d1 to
22a5353
Compare
Fixes #79
Closes #80
Most test cases are inherited from #80 while I also commented some differences.
@stulov Thank you for your work, which is very helpful.