397104 - Blockcomment containing at least one newline not treated as newline

Status: RESOLVED DUPLICATE of bug 475834

(Core :: JavaScript Engine, defect)

Description

[Hallvord R. M. Steen]

User-Agent:       Opera/9.20 (Windows NT 5.1; U; nb)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6

According to the ECMAScript spec, 

return /*

*/ someVariable;

should be executed as 

return 

someVariable;

i.e. return undefined, since automatic semicolon insertion will occur after return statement.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Hallvord R. M. Steen]

Attachment: Test case

Bug was actually found by David Andersson (liorean)

Comment 2

[Bob Clary [:bc] (inactive)]

7.4 Comments

Comments behave like white space and are discarded except that, if a MultiLineComment contains a line terminator character, then the entire comment is considered to be a LineTerminator for purposes of parsing by the syntactic grammar.

7.9.1 Rules of Automatic Semicolon Insertion


ReturnStatement :
    return [no LineTerminator here] Expressionopt ;

Comment 3

[Jesse Ruderman]

Brendan, would you like me to fuzz to find more bugs of this type?  If you think it's worth it, I can look for more bugs where "/*\n*/" and "\n" don't result in the same decompilation or disassembly (assuming bug 396512 gets fixed) or syntax error message.

Comment 4

[David "liorean" Andersson]

Opera has the only browser hosted ECMAScript engines that comply to this part of the ES3 spec. Wouldn't it be better for interoperability to change the spec behaviour instead of all those "broken" engines?

I doubt there are any developers out there who expects that /**/ and /*\n*/ will give different results.

Comment 5

[André Bargull [:anba]]

This is a dup of bug 475834, which in turn has been fixed in 1.9.1, so this bug report can be closed as well.

Comment 6

[Brendan Eich [:brendan]]

Dup'ing forward.

/be