Closed Bug 1609013 Opened 5 years ago Closed 5 years ago

Falsey if-statement produces empty completion value

Categories

(Core :: JavaScript Engine, defect, P3)

73 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1317378

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

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

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) {}"))
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3

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

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.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.