Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Change more
Completion() to ? (GetValue tricky)
Specifically, change occurrences of: ``` 1. Let _ref_ be Completion(Evaluation of X). 1. ... ? GetValue(_ref_) ... 1. (later references to _ref_) ``` to: ``` 1. Let _ref_ be ? Evaluation of X. 1. ... ? GetValue(_ref_) ... 1. (later references to _ref_) ``` In the following case analysis, let "CR" denote the value returned by `Evaluation of X` (always a Completion Record), and, if it's a normal completion, let "V" denote the value in its [[Value]] field. Before the change: If CR is an abrupt completion: it is bound to _ref_, then passed to GetValue, which executes ReturnIfAbrupt on it, i.e. returns it from GetValue, and the `?` before GetValue returns it from the algorithm. If CR is a normal completion: _ref_ is bound to it, then passed to GetValue, which would execute ReturnIfAbrupt on it, which would unwrap it to V. The rest of GetValue then operates on V, and then, in any event, returns some completion record, not necessarily the same as CR. (Note that _ref_ remains bound to CR.) After the change: If CR is an abrupt completion: the `?` before Evaluation returns it from the algorithm. (So, the same net effect as before.) If CR is a normal completion: the `?` before Evaluation unwraps it to V, _ref_ is bound to V, then passed to GetValue. GetValue's ReturnIfAbrupt has no effect on V, and the rest of GetValue operates on V, and returns some completion record, not necessaily the same as CR. (So, the same effect as before, *except* that _ref_ is bound to V, not CR. This difference is important because of the later references to _ref_.) To summarize: if the result of `Evaluation of X` is a normal completion, then in the status quo, the later references to _ref_ are references to that Completion Record, but with this commit, they would be references to the [[Value]] of that Completion Record. However, I believe that in every case, that difference either doesn't matter, or it fixes an editorial bug. Example of "doesn't matter": In some cases, the only later reference is where _ref_ is passed to the first parameter of PutValue, which immediately calls ReturnIfAbrupt on it, so it doesn't matter if _ref_ refers to the Completion Record or its [[Value]]. Example of "fixes an editorial bug": In the Evaluation rule for `CallExpression : CoverCallExpressionAndAsyncArrowHead` the next step says: ```If _ref_ is a Reference Record, ...``` In the "Before" world, where _ref_ is bound to a Completion Record, this test is never true. Another example: In many cases, the value of _ref_ is passed (directly or indirectly) to the second parameter of EvaluateCall, which requires "an ECMAScript language value or a Reference Record". In the "Before" world, _ref_ is bound to a Completion Record, which is not what's required. Prior to the merge of PR tc39#2547, these cases would have caused an implicit unwrapping from the Completion Record to its [[Value]], but tc39#2547 removed the idea of implicit unwrapping, so these references have been editorial bugs since then.
- Loading branch information
