Falsey if-statement produces empty completion value
Categories
(Core :: JavaScript Engine, defect, P3)
Tracking
()
People
(Reporter: spencer.wilson, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.117 Safari/537.36
Steps to reproduce:
Evaluate the code 1; if (false) {}
in the console of Firefox 73.0b4.
Actual results:
The REPL prints the value 1
.
Expected results:
The REPL should print the value undefined
. This is motivated by the ECMAScript spec, which states that a StatementList should evaluate to value of the last "value-producing" statement in the list. "Value-producing" is defined by the UpdateEmpty abstract operation [1], which reduces two CompletionRecords together, melding the CompletionRecord of the later statement into the former if its [[Value]] field is not empty
. It seems that in SpiderMonkey, the [[Value]] field of "if (false) {}" may be empty
when it should actually contain the value undefined
.
Chrome 79.0.3945.117 and Safari 13.0.4 (14608.4.9.1.4) both evaluate the StatementList given in the repro steps to undefined
.
[1] https://www.ecma-international.org/ecma-262/10.0/index.html#sec-updateempty
Reporter | ||
Comment 1•5 years ago
|
||
As an additional reference, the "BlockStatement: Evaluation" section is where the evaluation for "StatementList" is defined: https://www.ecma-international.org/ecma-262/10.0/index.html#sec-block-runtime-semantics-evaluation
Comment 2•5 years ago
|
||
My blind guess would be that this is a consequence of an optimization made in the front-end of SpiderMonkey which removes if (false)
branches from the code. This issue can be reproduced with an eval
statement:
print(eval("1; if (false) {}"))
Reporter | ||
Comment 3•5 years ago
|
||
The following might be evidence that the bug isn't completely explained by an errant static optimization:
eval('f = "foo" in window; 1; if (f) {}')
// returns 1 in Firefox, undefined elsewhere
Comment 4•5 years ago
|
||
I think we've known about bad completion value handling, to some degree, for awhile. The likely culprit is our constant-folding optimizations causing "dead" code that can be demonstrated to execute in certain fashion to be removed, without thinking about its effect on completion value. On the scale of bugs to fix, this certainly is one...but also it's going to be pretty low priority.
Description
•