/[\w-e]/ could have been valid

[icefapper]

Hello
In B.1.4 In ECMAScript 2015 spec, there were a number of productions that, due to a probably minor ordering mistake, have been actually dropped in the latest version of the spec, namely ES 2017:

NonemptyClassRanges [U] ::
ClassAtom [?U]
ClassAtom [?U] NonemptyClassRangesNoDash [?U]
[~U] ClassAtomInRange - ClassAtomInRange ClassRanges

NonemptyClassRangesNoDash [U] ::
ClassAtom [?U]
ClassAtomNoDash [?U] NonemptyClassRangesNoDash [?U]
[~U] ClassAtomNoDashInRange - ClassAtomInRange ClassRanges

ClassAtomInRange ::

ClassAtomNoDashInRange

ClassAtomNoDashInRange ::
SourceCharacter but not one of \ or ] or -
\ ClassEscape but only if ClassEscape evaluates to a CharSet with exactly one character
\ IdentityEscape

parsing using the rules above, /[\w-e]/ fails (please note the absence of the 'u' flag): ClassAtom [?U] NonemptyClassRangesNoDash [?U] fails to match \w-e, and the next production to test against is this: [~U] ClassAtomInRange - ClassAtomInRange ClassRanges, which is going to fail, since ClassAtomInRange won't match \w, because it is not "evaluat[ing] to a CharSet with exactly one character."

However, /[\w-e]/ would have been a valid RE in extended mode had the first two rules been:

NonemptyClassRanges [U] ::
ClassAtom [?U]
[~U] ClassAtomInRange - ClassAtomInRange ClassRanges
ClassAtom [?U] NonemptyClassRangesNoDash [?U]

NonemptyClassRangesNoDash [U] ::
ClassAtom [?U]
[~U] ClassAtomNoDashInRange - ClassAtomInRange ClassRanges
ClassAtomNoDash [?U] NonemptyClassRangesNoDash [?U]

This way, the RE /[\w-e]/ would have been interpreted as a set consisting of \w, -, and e, not as a range which will, anyway, be a treated as a syntax error. This, indeed, is the way Chrome 51, Safari, and Firefox 47 behave ( for example, "l-e".match( /[\w-e]/g returns ["l","-","e"] ) .

This makes me wonder whether it is a bug in the implementations, or an actually mistaken ordering in the spec (along with the subsequent omission of the productions altogether.) Or it might, more probably, be that I'm miserably mistaken.

Either way, it would be great to have an answer.

Thanks a lot reading this far!

[littledan]

cc @hashseed

[littledan]

cc @hashseed

[hashseed]

I would argue that [\w-e] should indeed be parsed the same as [-e\w].

[hashseed]

I would argue that [\w-e] should indeed be parsed the same as [-e\w].

[icefapper]

@hashseed
that is my point actually; But I could not come up with any sub-production of ClassRanges that would lead to [\w-e] being parsed as a class consisting of ClassAtom(\w) , ClassAtom(-), and ClassAtom(e).

Thanks a lot in advance for any clarifications!

[icefapper]

@hashseed
that is my point actually; But I could not come up with any sub-production of ClassRanges that would lead to [\w-e] being parsed as a class consisting of ClassAtom(\w) , ClassAtom(-), and ClassAtom(e).

Thanks a lot in advance for any clarifications!

[icefapper]

/cc @allenwb

[icefapper]

/cc @allenwb

[littledan]

Looking back at this bug, I'm not sure what the intent was of the filing. I don't see the language "but only if ClassEscape evaluates to a CharSet with exactly one character" in the current spec text. That language was removed by fbdfda6 , which landed before this bug was filed.

In the new spec text that @anba wrote in that patch, rather than using a grammar restriction, there is a SyntaxError thrown in evaluation, as part of CharacterRange, and in Annex B 1.4, this is replaced by CharacterRangeOrUnion, which implements the behavior @icefapper observed in browsers. cc @schuay

[littledan]

Looking back at this bug, I'm not sure what the intent was of the filing. I don't see the language "but only if ClassEscape evaluates to a CharSet with exactly one character" in the current spec text. That language was removed by fbdfda6 , which landed before this bug was filed.

In the new spec text that @anba wrote in that patch, rather than using a grammar restriction, there is a SyntaxError thrown in evaluation, as part of CharacterRange, and in Annex B 1.4, this is replaced by CharacterRangeOrUnion, which implements the behavior @icefapper observed in browsers. cc @schuay

[icefapper]

Thanks for the response.
The reason I opened this issue was because I had used the (outdated?) spec on ECMA's website, rather than the one on this repository (which is getting updated on a regular basis.)

[icefapper]

Thanks for the response.
The reason I opened this issue was because I had used the (outdated?) spec on ECMA's website, rather than the one on this repository (which is getting updated on a regular basis.)