In 15.2.1.16.1 "ParseModule ( sourceText ) Abstract Operation",
steps 2 + 3 says:
2. Parse /sourceText/ using /Module/ as the goal symbol and analyze the parse
result for any Early Error conditions. If the parse was successful and no
early errors were found, let /body/ be the resulting parse tree. Otherwise,
let /errors/ be an indication of one or more parsing errors and/or early
errors.
3. If /errors/ is an abrupt completion or error indication, then
...
Unusually for this spec, step 2 names two metavariables, but any given execution of the step will bind a value to only one of them. So when step 3 refers to the
/errors/ metavariable, it might not even be defined. (Everywhere else, I would take this as a bug in the spec, but here it's presumably intentional.)
Section 15.1.9 (ScriptEvaluationJob) has a step with parallel wording, but there it introduces just one metavariable, which is either bound to a parse tree or an error-indication as appropriate. The subsequent step can then refer to that variable without the chance that it's not defined.
I suggest using 15.1.9's approach in 15.2.1.16.1.
For the name of the single metavariable, I'd suggest the neutral /parseResult/.
fixed in rev34 editor's draft
I used "body" as the name of the single variable, as it is only in step 3 that that it may be anything other than the parse tree of the module body.
(In reply to Allen Wirfs-Brock from comment #1)
>
> I used "body" as the name of the single variable, as it is only in step 3
> that that it may be anything other than the parse tree of the module body.
Yup, that's reasonable.
(Although technically, because sourceText is parsed as a Module, it might make more sense to call it /module/. Note that /body/ suggests ModuleBody, but it might not be a ModuleBody, it might be [empty].)
fixed in rev34