New batch of error reports

[André Bargull]

On 7/3/2013 8:37 AM, A. Sundararajan wrote:
> * Yes - function-declaration-as-statement is allowed in nashorn for 
> compatibility with other impls.
>
> nashorn jjs tool has these 2 options:
>
> --function-statement-error (Report an error when function declaration 
> is used as a statement.)
>         param: [true|false]   default: false
>
> --function-statement-warning (Warn when function declaration is used 
> as a statement.)
>         param: [true|false]   default: false
>
> * On unnamed function declaration: again this seems to be allowed by 
> rhino as well. Also, using script engine API, it is possible to eval 
> an anon-func-declaraion and call the resulting the script function 
> object:
>
> Example:
>
>     var m = new javax.script.ScriptEngineManager();
>     var e = m.getEngineByName("nashorn");
>     var func = e.eval("function() { print('Anon function') }");
>     func();
>

Ah ok, that means `eval("function(){}")` is also possible in Nashorn 
(I've just checked it), whereas SpiderMonkey/JSC/V8 etc. report a 
SyntaxError in this case. Concerning Rhino and unnamed function 
declarations, I remember having done something like this one [1] once. :-)


[1] https://github.com/mozilla/rhino/pull/39/files#L72R810

> * On for..each: I'll file a sub-task to report error in this case. 
> Thanks for checking with SpiderMonkey.
>
> Thanks
> -Sundar
>
> On Wednesday 03 July 2013 11:53 AM, André Bargull wrote:
>>
>> On 6/28/2013 7:49 PM, A. Sundararajan wrote:
>>> Hi,
>>>
>>> I've filed one big umbrella issue for all the issues that you sent 
>>> today. (JDK-8019398).
>>>
>>> Two observations:
>>>
>>> * with({}) function() {}
>>>
>>> seems to be accepted by rhino as well.  Need to check with what 
>>> spec. says though.
>>
>> It's an error per spec, because
>> (1) FunctionDeclaration productions can only appear at top-level 
>> (that means in SourceElement)
>> (2) FunctionDeclarations must be named
>>
>> and it cannot be parsed as an ExpressionStatement due to the 
>> lookahead restriction in ExpressionStatement.
>>
>> For compatibility reasons number (1) needs to be dropped, that means 
>> the FunctionDeclaration production moves to the Statement production 
>> (with more or less custom semantics, es-discuss has several threads 
>> about this issue). But (2) still holds. And an unnamed function 
>> declaration is somewhat useless because it's never callable, isn't it?
>>
>>
>>>
>>> * for each with initializer - for each(var v=0;false;);
>>>
>>> is also permitted by rhino as well - "each" is treated as a noise 
>>> word in that case. Given that we included for..each for 
>>> compatibility with rhino, we might as well leave that noise word (or 
>>> is it a bug with rhino as well?)
>>>
>>
>> I'd call this a Rhino bug, too. By checking the commit history, I've 
>> found out that this bug was already present when E4X support w.r.t. 
>> for-each was initially added. SpiderMonkey reports an error for that 
>> code.
>>
>>
>> - André
>>
>>
>>> -Sundar
>>>
>>>
>>> On Friday 28 June 2013 03:04 PM, André Bargull wrote:
>>>> [....]
>>>
>>
>
>