Wrong tests in ecmascript-regex.json #285
Labels
bug
A test is wrong, or tooling is broken or buggy.
Comments
|
Thank you for quick fix. |
ChALkeR
added a commit
to ChALkeR/JSON-Schema-Test-Suite
that referenced
this issue
May 30, 2020
Looks like there was a bug at the time of introduction due to json-schema-org#285 Per ECMA 262 specification: https://www.ecma-international.org/ecma-262/10.0/index.html#sec-characterclassescape `\S` refers to `\s`: > # Section 21.2.2.12: > The production `CharacterClassEscape::S` evaluates as follows: > 1. Return the set of all characters not included in the set returned > by `CharacterClassEscape::s`. `\s` refers to `WhiteSpace`: > The production `CharacterClassEscape::s` evaluates as follows: > 1. Return the set of characters containing the characters that are on > the right-hand side of the WhiteSpace or LineTerminator > productions. `WhiteSpace` includes NBSP (**U00A0**): https://www.ecma-international.org/ecma-262/10.0/index.html#prod-WhiteSpace That is the exact opposite of what the current test was checking for. Also, `WhiteSpace` includes any other Unicode "Space_Separator" code points. That's not a new addition, same was true in version 6.0: * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-characterclassescape * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-white-space
ChALkeR
added a commit
to ChALkeR/JSON-Schema-Test-Suite
that referenced
this issue
May 30, 2020
Looks like there was a bug at the time of introduction due to json-schema-org#285 Per ECMA 262 specification: https://www.ecma-international.org/ecma-262/10.0/index.html#sec-characterclassescape `\S` refers to `\s`: > # Section 21.2.2.12: > The production `CharacterClassEscape::S` evaluates as follows: > 1. Return the set of all characters not included in the set returned > by `CharacterClassEscape::s`. `\s` refers to `WhiteSpace`: > The production `CharacterClassEscape::s` evaluates as follows: > 1. Return the set of characters containing the characters that are on > the right-hand side of the WhiteSpace or LineTerminator > productions. `WhiteSpace` includes NBSP (**U00A0**): https://www.ecma-international.org/ecma-262/10.0/index.html#prod-WhiteSpace That is the exact opposite of what the current test was checking for. Also, `WhiteSpace` includes any other Unicode "Space_Separator" code points. That's not a new addition, same was true in version 6.0: * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-characterclassescape * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-white-space
ChALkeR
added a commit
to ChALkeR/JSON-Schema-Test-Suite
that referenced
this issue
Jun 9, 2020
Looks like there was a bug at the time of introduction due to json-schema-org#285 Per ECMA 262 specification: https://www.ecma-international.org/ecma-262/10.0/index.html#sec-characterclassescape `\S` refers to `\s`: > # Section 21.2.2.12: > The production `CharacterClassEscape::S` evaluates as follows: > 1. Return the set of all characters not included in the set returned > by `CharacterClassEscape::s`. `\s` refers to `WhiteSpace`: > The production `CharacterClassEscape::s` evaluates as follows: > 1. Return the set of characters containing the characters that are on > the right-hand side of the WhiteSpace or LineTerminator > productions. `WhiteSpace` includes NBSP (**U00A0**): https://www.ecma-international.org/ecma-262/10.0/index.html#prod-WhiteSpace That is the exact opposite of what the current test was checking for. Also, `WhiteSpace` includes any other Unicode "Space_Separator" code points. That's not a new addition, same was true in version 6.0: * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-characterclassescape * https://www.ecma-international.org/ecma-262/6.0/index.html#sec-white-space
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello @Zac-HD
Some tests recently added by PR #282 seem to have wrong unicode escaping.
For example,
"data": "\\u07c0"should be"data": "\u07c0", because these values are not regular expressions. They are confused with the values ofpatternkeyword that should be of regular expression.The text was updated successfully, but these errors were encountered: