You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
/* Comment */
@import url('https://example');
html { font-size: 1em; }
Expected:
This input "looks" like CSS and is wrongly being fed to a JavaScript context. It should be rejected with a syntax error.
Actual:
The parser succeeds and returns akin to when the input is an empty string.
Peast::ES2016( $contents )->parse()
object(Peast\Syntax\Node\Program)[503]
protected 'propertiesMap' =>
array (size=2)
'body' => boolean true
'sourceType' => boolean false
public 'location' =>
object(Peast\Syntax\SourceLocation)[502]
public 'start' =>
object(Peast\Syntax\Position)[464]
protected 'line' => int 0
protected 'column' => int 0
protected 'index' => int 0
public 'end' =>
object(Peast\Syntax\Position)[464]
protected 'line' => int 0
protected 'column' => int 0
protected 'index' => int 0
protected 'leadingComments' =>
array (size=0)
empty
protected 'trailingComments' =>
array (size=0)
empty
protected 'sourceType' => string 'script' (length=6)
protected 'body' =>
array (size=0)
empty
Other:
I have narrowed this down as much as I can. It appears to be very specific to these combinations of tokens. For example, changing the last line from font-size: 1em to font-size: normal causes it to find the syntax error. Or, omitting only the comment, makes it find the error. Or, omitting only the @import line makes it find the error.
The text was updated successfully, but these errors were encountered:
The problem was caused by the initial comment. In some situation the scanner forgives an invalid character that comes after a slash because it can be part of a regexp, then it rescans it in "regexp mode" and does the final check.
In your code the @ comes after a slash, but that slash is the end of a comment so it can't be the start of a regexp and the scanner must not forgive it.
I've fixed the bug by making that check more strict, now it should cover all the cases.
Input:
Expected:
This input "looks" like CSS and is wrongly being fed to a JavaScript context. It should be rejected with a syntax error.
Actual:
The parser succeeds and returns akin to when the input is an empty string.
Other:
I have narrowed this down as much as I can. It appears to be very specific to these combinations of tokens. For example, changing the last line from
font-size: 1em
tofont-size: normal
causes it to find the syntax error. Or, omitting only the comment, makes it find the error. Or, omitting only the@import
line makes it find the error.The text was updated successfully, but these errors were encountered: