Use `v` regexp flag instead of `u` #178

nicolo-ribaudo · 2023-07-13T10:08:51Z

The v flags add more support to regular expression features:

"set operation", such as [[a-z]--[dhk]] to express "the set a-z, excluding the set dhk (https://github.com/tc39/proposal-regexp-v-flag)
multi-codepoint properties in \p, such as \p{RGI_Emoji_ZWJ_Sequence} (https://github.com/tc39/proposal-regexp-unicode-sequence-properties)

The HTML <input>'s pattern attribute has also been recently updated to use v instead of u (https://html.spec.whatwg.org/#compiled-pattern-regular-expression).

The text was updated successfully, but these errors were encountered:

bathos · 2023-07-13T14:31:18Z

The “set operations” would be useful. I‘m pretty sure the second never will be, though, because ...

$new URLPattern({ pathname: "/🍒" }).test("https://bar.com/🍒"); true new URLPattern({ pathname: "/(\p{Emoji})" }).test("https://bar.com/🍒"); false new URLPattern({ pathname: "/(\p{Ll})" }).test("https://bar.com/a"); true new URLPattern({ pathname: "/(\p{Ll})" }).test("https://bar.com/é"); false new URLPattern({ pathname: "/%F0%9F%8D%92" }).test("https://bar.com/🍒"); true$

— the illusion that non-ASCII is matchable is limited to literal input: it converts non-ASCII input to percent encoded UTF-8, but regexp pattern components aren’t likewise “translated”, so expressing things like \p{RGI_Emoji_Sequence} seems to always require input that’s similar to what transpilers might produce today for engines that don’t support multi- or single- codepoint properties at all.

This will fix #178.

This CL follows the recent spec update in [1]. After this CL, the regular expression works with the unicodeSet mode, which allows the API to interpret set notations, multi-codepoint properties etc. Actually, this CL ends up only adding the support for set notations. At the moment the API doesn't accept unicode character class escape (\p{}, \P{}) [2], thus we wouldn't add the multi-codepoint match functionarity. There are some incompatibility between "u" and "v", some patterns are privously valid but now errors. However, from UMA the impact looks very limited, it's only around 0.3% of the total constructor calls. So this CL changes the default flag to "v". Also add a kill switch. [1] whatwg/urlpattern#178 [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape Change-Id: I14cc3420d57cca44c0c25867d05802a8a666cd8c Bug: 1482263

This CL follows the recent spec update in [1]. After this CL, the regular expression works with the unicodeSet mode, which allows the API to interpret set notations, multi-codepoint properties etc. Actually, this CL ends up only adding the support for set notations. At the moment the API doesn't accept unicode character class escape (\p{}, \P{}) [2], thus we wouldn't add the multi-codepoint match functionarity. There are some incompatibility between "u" and "v", some patterns are privously valid but now errors. However, from UMA the impact looks very limited, it's only around 0.3% of the total constructor calls. So this CL changes the default flag to "v". Also add a kill switch. [1] whatwg/urlpattern#178 [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape Change-Id: I14cc3420d57cca44c0c25867d05802a8a666cd8c Bug: 1482263 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4861342 Reviewed-by: Jeremy Roman <jbroman@chromium.org> Commit-Queue: Shunya Shishido <sisidovski@chromium.org> Cr-Commit-Position: refs/heads/main@{#1221823}

…attern, a=testonly Automatic update from web-platform-tests Use kUnicodeSets (v regexp flag) in URLPattern This CL follows the recent spec update in [1]. After this CL, the regular expression works with the unicodeSet mode, which allows the API to interpret set notations, multi-codepoint properties etc. Actually, this CL ends up only adding the support for set notations. At the moment the API doesn't accept unicode character class escape (\p{}, \P{}) [2], thus we wouldn't add the multi-codepoint match functionarity. There are some incompatibility between "u" and "v", some patterns are privously valid but now errors. However, from UMA the impact looks very limited, it's only around 0.3% of the total constructor calls. So this CL changes the default flag to "v". Also add a kill switch. [1] whatwg/urlpattern#178 [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Regular_expressions/Unicode_character_class_escape Change-Id: I14cc3420d57cca44c0c25867d05802a8a666cd8c Bug: 1482263 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4861342 Reviewed-by: Jeremy Roman <jbroman@chromium.org> Commit-Queue: Shunya Shishido <sisidovski@chromium.org> Cr-Commit-Position: refs/heads/main@{#1221823} -- wpt-commits: 3ce3e9794fcd97ff24506f5c5325f91fc00ef79c wpt-pr: 43014

sisidovski self-assigned this Sep 13, 2023

sisidovski mentioned this issue Sep 13, 2023

Updates the regular expression to work with the v flag instead of u #188

Merged

jeremyroman mentioned this issue Sep 13, 2023

Matching ( and ) in a regexp matcher requires escaping #177

Open

sisidovski closed this as completed in #188 Sep 13, 2023

sisidovski added a commit that referenced this issue Sep 13, 2023

Updates the regular expression to work with the v flag instead of u

9504c41

This will fix #178.

chromium-wpt-export-bot mentioned this issue Nov 8, 2023

Use kUnicodeSets (v regexp flag) in URLPattern web-platform-tests/wpt#43014

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Use `v` regexp flag instead of `u` #178

Use `v` regexp flag instead of `u` #178

nicolo-ribaudo commented Jul 13, 2023

bathos commented Jul 13, 2023

Use v regexp flag instead of u #178

Use v regexp flag instead of u #178

Comments

nicolo-ribaudo commented Jul 13, 2023

bathos commented Jul 13, 2023

Use `v` regexp flag instead of `u` #178

Use `v` regexp flag instead of `u` #178