1361876 - Implement RegExp Unicode Property Escapes

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P2)

Description

[Leo Balter]

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.

Comment 1

[Leo Balter]

The skip list is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1362169

Comment 3

[Alexandre Folle de Menezes]

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.

Comment 4

[Nicolas B. Pierron [:nbp]]

Waldo, can you need-info the right person to address this issue?

Comment 5

[Jeff Walden [:Waldo]]

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

[André Bargull [:anba]]

(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

[Alexandre Folle de Menezes]

This was supported in Chrome 64 and now on Safari 11.1.  Maybe some "parity" tags should be added here.

Comment 9

[Nicolas B. Pierron [:nbp]]

This bug seems to be blocked on Bug 1367105.

Comment 11

[kamil.k.kielczewski]

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

[Nicolas B. Pierron [:nbp]]

This bug depends on Bug 1367105, which is now a P2.

Comment 14

[espen.klem]

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

[ariasuni]

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

[Iain Ireland [:iain]]

This will be landing in Firefox 78. It should be available in Nightly within a day or so. See bug 1634135.

Comment 17

[saleh]

🥳

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

[saleh]

@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

[ariasuni]

(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

[Iain Ireland [:iain]]

Fixed by the landing of bug 1634135.

Comment 22

[Florian Scholz (Open Web Docs)]

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