460687 - Top level function expression evaluates to undefined

Status: RESOLVED INVALID

(Rhino Graveyard :: Core, defect)

Description

[richard.evans]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.0.2) Gecko/2008092318 Fedora/3.0.2-1.fc9 Firefox/3.0.2
Build Identifier: Rhino 1.7 release 1 2008 03 06 

I have a function expression in a Java string that I need to set as a property on an existing Scriptable.

If I try:

x = context.evaluateString(scope, "function() { return 1}", "", 1, null);

the result is undefined.  If I surround the function in brackets, I get a Function object:

x = context.evaluateString(scope, "(function() { return 1})", "", 1, null);

Is this intended behaviour?  You can demonstrate this in the JavaScript shell:

Rhino 1.7 release 1 2008 03 06
js> function () { return 1; }
js> (function () { return 1; })

function () {
    return 1;
}

js> 

Seems inconsistent to get different results with or without brackets.  I guess I can call compileFunction here, but I was wondering why evaluateString didn't work.

Reproducible: Always

Steps to Reproduce:
Run the JavaScript shell.  Enter:

js> function() { return 1; }
js> (function() { return 1; })
Actual Results:  
No output from first expression; decompiled function from second expression

Expected Results:  
Same output form both?

Comment 1

[Cameron McCormack (:heycam)]

If the string passed to evaluateString() is interpreted as a Program (http://bclary.com/2004/11/07/#a-14) then "function(){return 1}" is a Program with one FunctionDeclaration and no Statements.  Such a Program doesn't evaluate to a value.

Well, in the spec it is defined to evaluate to a Completion value of (normal,empty,empty).  An ExpressionStatement "(function(){return 1})" on the other hand is defined to evaluate to a Completion value of (normal,V,empty) where V is a Function object.  But the Completion type really is just a spec formalism, and it isn't defined how Completion values get turned into appropriate values for interfaces like Context.evaluateString().  I think it's reasonable for (normal,empty,empty) to be returned from evaluateString() as the Java value representing the JS undefined value.

(This bug can be resolved invalid IMO.)

Comment 2

[Hannes Wallnoefer]

I think Cameron's comment is valid, resolving as invalid.