Editorial: Move module TopLevelCapability check inside if

[nicolo-ribaudo]

Current spec:

Proposed spec:

---

In the current spec, the condition in step 4 can only be true if the condition in step 3 was true. Moving step 4 as a sub-step of step 3 makes it clearer, without the next reader having to wonder how we can hit the control flow path with 3 false and 4 true.

Proof:

For convenience, I'm going to call module the value that the module variable has starting from step 3.a.i/4, and originalModule the "this value" of the Evaluate() concrete method. module is either originalModule or its [[CycleRoot]].

If 4 is true, it's because module already went through step 7 of Evaluate(), since that's the only place where [[TopLevelCapability]] is set. This means that module.[[Status]] is either already ~evaluated~ (asserted in steps 9.b and 10.a) or (~evaluating-async~).

originalModule was in that previous call either module itself, or part of a cycle containing both. A cycle transitions to ~evaluated~/~evaluating-async~ atomically (steps 16.b.v and 16.b.vi of InnerModuleEvaluation), which means that originalModule is also either evaluated or evaluating-async.

Thus if 4 is true, 3 must have been true.

[github-actions]

The rendered spec for this PR is available at https://tc39.es/ecma262/pr/3742.

[linusg]

Reasoning seems correct to me.

[nicolo-ribaudo]

Hey please do not spend time reviewing this PR yet, I do not agree with the second paragraph of my "proof". More specifically, I do not clearly see anymore why module could not be ~evaluating~ (it technically follows from the assertion in step 1, but Node.js actually violates that assertion, and the import defer proposal will relax it).