Editorial: Fixed return types of algorithms returning ~empty~

[jhnaldo]

We found the return type bug in the syntax-directed operation: 15.7.12 Runtime Semantics: EvaluateClassStaticBlockBody via ESMeta type analyzer.

Currently, the type of CatchClauseEvaluation is defined as follows:

Runtime Semantics: EvaluateClassStaticBlockBody (
  _functionObject_: a function object,
): either a normal completion containing an ECMAScript language value or an abrupt completion

However, I think its return type should contain a normal completion containing ~empty~.

In step 2 for, it returns the result of Evaluation of |ClassStaticBlockStatementList|. Because of the implicit definition of operations for chain productions (ClassStaticBlockStatementList -> StatementList -> StatementListItem -> Statement -> BlockStatement -> Block), the Evaluation of |Block| might be invoked, and it returns a normal completion containing ~empty~. Thus, CatchClauseEvaluation algorithm could return a normal completion containing ~empty~.

Therefore, I suggest extending its return type as follows:

         Runtime Semantics: EvaluateClassStaticBlockBody (
           _functionObject_: a function object,
-        ): either a normal completion containing an ECMAScript language value or an abrupt completion
+        ): either a normal completion containing either an ECMAScript language value or ~empty~, or an abrupt completion

In addition, we found similar bugs in the following algorithms:

• 10.2.1.3 Runtime Semantics: EvaluateBody
• 10.2.1.4 OrdinaryCallEvaluateBody
• 14.13.4 Runtime Semantics: LabelledEvaluation
• 14.15.2 Runtime Semantics: CatchClauseEvaluation
• 15.2.3 Runtime Semantics: EvaluateFunctionBody

[michaelficarra]

LGTM.

[michaelficarra]

I've rebased this on #2966.

[bakkot]

I agree this is broken but I think there's a better way to fix it. I'll try to write it up.

[bakkot]

I've pushed a commit which handles the changes to EvaluateBody/OrdinaryCallEvaluateBody/EvaluateFunctionBody/EvaluateClassStaticBlockBody by instead having EvaluateBody only ever return return/throw completions. The other branches of EvaluateBody already have this property; it was just the ordinary function case and the class static block case which needed to be updated to do this. Then OrdinaryCallEvaluateBody no longer has to deal with normal completions at all: evaluating a function body is guaranteed to give you a return completion or throw completion.

In essence this means that the "implicit return" case (i.e., walking past the end of a function body) is now handled in EvaluateFunctionBody instead of higher up the call chain in OrdinaryCallEvaluateBody, which I consider nicer because it means fewer things need to deal with propagating a normal completion which will be end up being equivalent to a return completion holding undefined.

The fact that EvaluateBody gives specifically return/throw completions, and not break/continue completions, follows from the syntax rules preventing break/continue statements crossing function boundaries. Unfortunately, though understandably, esmeta can't recognize this invariant, so it still ends up needing a few things in esmeta-ignore.

[syg]

lgtm. This is great.