-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: add RegExp lookbehind to annex-B #1102
Conversation
This indeed looks like an oversight to me. |
spec.html
Outdated
@@ -40918,7 +40922,7 @@ <h1>Pattern Semantics</h1> | |||
1. Return _m_. | |||
</emu-alg> | |||
|
|||
<p>Assertion (<emu-xref href="#sec-assertion"></emu-xref>) evaluation rules for the <emu-grammar>Assertion :: `(` `?` `=` Disjunction `)`</emu-grammar> and <emu-grammar>Assertion :: `(` `?` `!` Disjunction `)`</emu-grammar> productions are also used for the |QuantifiableAssertion| productions, but with |QuantifiableAssertion| substituted for |Assertion|.</p> | |||
<p>Assertion (<emu-xref href="#sec-assertion"></emu-xref>) evaluation rules for the <emu-grammar>Assertion :: `(` `?` `=` Disjunction `)`</emu-grammar>, <emu-grammar>Assertion :: `(` `?` `!` Disjunction `)`</emu-grammar>, <emu-grammar>Assertion :: `(` `?` `<=` Disjunction `)`</emu-grammar>, and <emu-grammar>Assertion :: `(` `?` `<!` Disjunction `)`</emu-grammar> productions are also used for the |QuantifiableAssertion| productions, but with |QuantifiableAssertion| substituted for |Assertion|.</p> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we actually want to enable lookbehind in QuantifiableAssertion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should make sure to have a test262 test one way or the other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note: I confirmed it on Chrome 65 since Annex B is the section for browser compatibility. Lookbehind assertions are quantifiable on the Chrome.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have to make a conscious decision between: (A) be consistent with other assertions of the form This PR apparently chose (A). I would prefer (B). (Also, because a choice is needed, this PR is not ”editorial”.) |
So if I understand correctly, the question is whether to allow something like I honestly don't see a reason why this should be allowed since these assertions do not consume any characters, and therefore seem rather pointless. Btw. if we decide for (B), I will need to fix V8. |
spec.html
Outdated
[~U] QuantifiableAssertion[?N] | ||
|
||
QuantifiableAssertion[N] :: | ||
`(` `?` `=` Disjunction[~U, ?N] `)` | ||
`(` `?` `!` Disjunction[~U, ?N] `)` | ||
`(` `?` `<=` Disjunction[?U, ?N] `)` | ||
`(` `?` `<!` Disjunction[?U, ?N] `)` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's an error to use '?U' here, because QuantifiableAssertion doesn't have a 'U' parameter.
OK, seems like we're pretty unanimous in this thread so far that QuantifiableAssertion should not support positive or negative lookbehinds. @mysticatea would you be up for writing a new patch with that change, and then we can discuss it at the March 2018 TC39 meeting to confirm broader consensus? |
ac7ccb8
to
de64f38
Compare
I updated this PR. |
de64f38
to
c6941f3
Compare
FWIW we have this comment in V8 implemented back in January 2016:
I guess the change would be to
|
@hashseed I think that's what the current patch does. The grammar here (EDIT: Namely, in Annex B section 1.4) only is relevant on non-Unicode RegExps. From the introduction to the section:
@bterlson and I were just puzzling over what those |
I think all three of @hashseed's bullets are accomplished in the current spec. This patch does something else. |
V8 fix in flight: https://chromium-review.googlesource.com/c/v8/v8/+/926102 |
@jmdyck How does the current spec support lookbehind at all when taking the Annex B grammar into account? |
The current spec doesn't, this patch does. (Allowing lookbehinds wasn't one of @hashseed's bullets.) |
@jmdyck I think we actually do want to enable lookbehinds, just not as a quantifiable assertion. Given that goal, do you think this patch seems good? |
Yes, the patch is necessary. 21.2.1 has lookbehinds, so annex B must have them too. |
- Tests that lookahead and lookbehind are not extended to QuantifiableAssertion, as in tc39/ecma262#1102 - Additional tests verifying some more combinations of cases for QuantifiableAssertion being invalid in Unicode mode. Based on the tests in https://chromium-review.googlesource.com/c/v8/v8/+/926102 These tests pass on V8 (if the throw for early errors is removed to work around a V8 issue where RegExps don't have early errors).
See tests at tc39/test262#1456 |
At this point, we have
Do we have consensus on this normative change? I've added it to the March 2018 meeting agenda so we can confirm consensus there if necessary. |
Thanks for this PR, and sorry for the delay in getting it pulled in! |
…rn evaluate semantics in annex b Bugfix: When speccing lookbehind assertions (PR tc39#1102), a `direction` parameter were added, in particular to the `evaluate` semantics of Atom productions and to the CharacterSetMatcher abstract operation. The ExtendedAtom productions found in Annex B were forgotten to be amended in the same way.
This PR adds the syntax of RegExp Lookbehind Assertions into B.1.4 Regular Expressions Patterns section.
Since #1029 didn't look to update the Annex-B section but I think it's needed (#1029 (comment)).
I apologize if it's intentional.