Implement RegExp Unicode Property Escapes
Categories
(Core :: JavaScript Engine, enhancement, P2)
Tracking
()
People
(Reporter: leonardo.balter, Unassigned)
References
()
Details
(Keywords: dev-doc-complete, parity-chrome, parity-safari)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 Steps to reproduce: Currently featured at TC39 as a Stage 3 proposal. https://github.com/tc39/proposal-regexp-unicode-property-escapes Test262 holds the tests with the `regexp-unicode-property-escapes` flag and in the `built-ins/RegExp/property-escapes/` folder. I'm updating the jstests.list to reflect all the matching test files.
Updated•6 years ago
|
Reporter | ||
Comment 1•6 years ago
|
||
The skip list is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1362169
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 3•5 years ago
|
||
This proposal was approved by TC39 and is now part of the ES2018 standard. It is already supported by current Chrome and by Safari TP.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Waldo, can you need-info the right person to address this issue?
Comment 5•5 years ago
|
||
If Chrome and Safari already implement this, it's probable updating our irregexp import (which is being worked on now, in bug 1367105) will mean that (without too much hookup work) we'll just Get This Sort Of For Free. (There of course may be complexities involved in matching up their implementation approaches with the data we have available, for example if they implement this feature with a hard dependency on ICU -- a dependency we don't have when --without-intl-api.) Poking anba at this, although I'm not sure what exactly a needinfo here is going to do other than be mostly noise.
Comment 6•5 years ago
|
||
(In reply to Jeff Walden [:Waldo] from comment #5) > (There of course may be complexities involved in matching up their > implementation approaches with the data we have available, for example if > they implement this feature with a hard dependency on ICU -- a dependency we > don't have when --without-intl-api.) Yes, it's going to be a hard dependency on ICU, so --without-intl-api won't get Unicode property escapes. Clearing NI because comment #5 exactly describes the current situation (requires irregexp update and then we get it basically for free).
Comment 7•5 years ago
|
||
This was supported in Chrome 64 and now on Safari 11.1. Maybe some "parity" tags should be added here.
Updated•5 years ago
|
Comment 9•5 years ago
|
||
This bug seems to be blocked on Bug 1367105.
Updated•5 years ago
|
Comment 11•5 years ago
|
||
ONELINER testcase (from duplicate: 1500035) - this regexp should block numbers (on Chrome/Safari works, on ff not):
> <input type="text" name="field" onkeydown="return /\p{L}/u.test(event.key)" >
Comment 12•5 years ago
|
||
This bug depends on Bug 1367105, which is now a P2.
Updated•4 years ago
|
Comment 14•4 years ago
|
||
Just wondering where this enhancement stands? I know it's a minor thing, but it would be great for creating libraries with true multi-language support for the browser.
Comment 15•3 years ago
|
||
The lack of Unicode-awareness on RegExp
, even when using flag u
, makes Mozilla’s own extension B!tch to Boss buggy, since it rely on \b
to detect word boundaries. More generally, as someone else put it, «This makes the RegEx character classes largely useless for dealing with any real language.».
I’m posting this here since it may be considered part of the same issue, as:
(In reply to Jeff Walden [:Waldo] from comment #5)
If Chrome and Safari already implement this, it's probable updating our irregexp import […] will mean that […] we'll just Get This Sort Of For Free.
Comment 16•3 years ago
|
||
This will be landing in Firefox 78. It should be available in Nightly within a day or so. See bug 1634135.
Comment 17•3 years ago
•
|
||
🥳
Just to Confirm…
This means we can start writing this:
/[_$\p{ID_Start}][_$\u200c\u200d\p{ID_Continue}\u034f]*/u
Instead of this:
/[_$a-zA-Z\xaa (very long regular expression here) \u034f]*/u
… right?
Comment 19•3 years ago
|
||
@svnpenn You get no apologies from me, and the fact that you are somehow still on this thread is unacceptable.
My apologies to everyone else, it was not intended as spam, but my apologies all the same. I am still curious to the specifics, because the discussion points to \b
which is much more subtle compared to \p
which is implied by the op, and trying to pinpoint it in the linked threads is proving hard.
I do appreciate the moderation of my long expression, which I was not aware is problematic in this community. I would appreciate folks moderate their inbox, and accept my apologies.
Comment 20•3 years ago
|
||
(In reply to Iain Ireland [:iain] from comment #16)
This will be landing in Firefox 78. It should be available in Nightly within a day or so. See bug 1634135.
Thanks, this looks an awesome update to Firefox! I’ve updated my review on the extension to link to the bug you mention.
Comment 21•3 years ago
|
||
Fixed by the landing of bug 1634135.
Updated•3 years ago
|
Comment 22•3 years ago
|
||
Developer docs:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/78#JavaScript
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/RegExp
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Unicode_Property_Escapes
Description
•