Upgrade to Esprima 3.0.0-rc-03 #1596
Conversation
There was a problem hiding this comment.
I'm not sure whether we should also address this Unicode mode (flag u) problem:
There could be false positive empty string matches in the middle of surrogate pairs. Patterns as simple as /a?/ have this issue when the input string contains astral Unicode chars. I didn't find a workaround for this but I'm pretty sure that, if it's exists, it's very complicated. This is a big problem but can be mitigated somewhat using a bit of "post-processing", that is, filtering out the false positive matches after evaluation like it's done here. I'm afraid we can't do anything better than this until .NET adds the options to treat the input string as Unicode code points.
If the issue is not clear, just check the output of this expression: [..."💩".matchAll(/a?/ug)]. It should return only 2 matches (with index 0 and 2) but Jint will report 3 matches (an extra fake one with index 1) unless we do something about it.
What do you think? Should we, as a best effort, remove such false positive matches during regex evaluation? I'm not familiar with the Jint internals but I suppose it could be done by adjusting RegExpPrototype.
Co-authored-by: adams85 <31276480+adams85@users.noreply.github.com>
Co-authored-by: adams85 <31276480+adams85@users.noreply.github.com>
|
I think you are the best authority to assess this as you've gone so deep with regex parsing. Jint generally just tries its best with produced regexes. Many seem as quite advanced scenarios so not sure how often people will hit limitations. Maybe after this has been merged you could check if you can work some magic on Jint side? No pressure as Jint probably isn't your main scenario to tweak Esprima 🙂 |
|
Sure thing. I'll have a look soon if the situation can be improved. |
No description provided.