Serenity: LibRegex: Couple parser syntax issues

[Lubrsi]

From google.com:

Browser(24): [PARSER] Error: Unexpected token Plus. Expected: Char
Browser(24): [PARSER] Error: Unexpected token Slash. Expected: Char
Browser(24): Throwing JavaScript Error: SyntaxError, RegExp compile error: 'Error during parsing of regular expression:
    ^[\w+/_-]+[=]{0,2}$
        ^---- Invalid character class type referenced.
'
Browser(24):   <anonymous>
Browser(24):   (global execution context)

JQuery <1.6.3

Browser(24): [PARSER] Error: Unexpected token HyphenMinus. Expected: RightParen
Browser(24): Throwing JavaScript Error: SyntaxError, RegExp compile error: 'Error during parsing of regular expression:
    ^(?:[^<]*(<[\w\W]+>)[^>]*$|#([\w\-]*)$)
                                     ^---- ( ) imbalance.
'
Browser(24):   <anonymous>
Browser(24):   <anonymous>
Browser(24):   (global execution context)

[linusg]

I have more:

> /{/
Error during parsing of regular expression:
    {
    ^---- Invalid regular expression.

> /\//
Error during parsing of regular expression:
    \/
     ^---- Invalid character class type referenced.

[bcoles]

[alimpfard]

/^[\w+/_-]+[=]{0,2}$/

Not sure what's going on, I'll get back to you on this :P

/^(?:[^<]*(<[\w\W]+>)[^>]*$|#([\w\-]*)$)/

That's interesting, \- in character classes is only allowed in unicode mode for whatever reason, though the parser does switch to it in some scenarios...:thinking:

/{/

This is not valid (as per the spec): Atom > PatternCharacter > "SourceCharacter but not SyntaxCharacter"
https://www.ecma-international.org/ecma-262/#prod-Atom
https://www.ecma-international.org/ecma-262/#prod-SyntaxCharacter

/\//

I guess that has been forgotten...oops

[alimpfard]

I might be reading the spec wrong, but.../\// isn't allowed in non-unicode mode?
here's what I can see:

(https://www.ecma-international.org/ecma-262/#sec-regexpinitialize)
If F contains "u", let BMP be false; else let BMP be true.
If __BMP is true__, then
Let pText be the sequence of code points resulting from interpreting each of the 16-bit elements of P as a Unicode BMP code point. UTF-16 decoding is not applied to the elements.
Parse pText using the grammars in 21.2.1. The goal symbol for the parse is __Pattern[~U, ~N]__. If the result of parsing contains a GroupName, reparse with the goal symbol __Pattern[~U, +N]__ and use this result instead. Throw a SyntaxError exception if pText did not conform to the grammar, if any elements of pText were not matched by the parse, or if any Early Error conditions exist.

Seems like not passing 'u' as a flag makes /\// invalid (at least, as far as the spec is concerned)

[alimpfard]

@bcoles what exactly is wrong with the \r and \n cases? the first looks for carriage returns (and there are none in that file), the second looks for newlines, and there _are_ newlines (note that \n in double-quoted strings is a shell escape - replaced with a newline).

[bcoles]

@bcoles what exactly is wrong with the \r and \n cases? the first looks for carriage returns (and there are none in that file), the second looks for newlines, and there _are_ newlines (note that \n in double-quoted strings is a shell escape - replaced with a newline).

grep states it skipped the binary file stdin in both scenarios. Clearly stdin was not skipped given that the output for both scenarios differs. Also stdin is not a binary file.

[alimpfard]

/\// isn't allowed in non-unicode mode?

Actually, any unrecognised escape is allowed in non-unicode mode, I'm just really bad at reading specs apparently.

[awesomekling]

@alimpfard wait I don't think this fixed ^[\w+/_-]+[=]{0,2}$

[alimpfard]

It seems to parse okay though?

[alimpfard]

heck, that's part of the test suite now :/

[awesomekling]

Oh whoops, my bad! I didn't compile before testing, duh 😇