Merge pull request #51 from littledan/hooked

Normative: Flush Job Queue between module imports

README.md

@@ -274,7 +274,9 @@ Currently (in a world without top-level `await`), polyfills are synchronous. So,
 
 Yes. In particular, if none of the imported modules have a top-level `await`, there will still be a delay of some turns on the Promise job queue until the module body executes. The goal here is to avoid too much synchronous behavior, which would break if something turns out to be asynchronous in the future, or even alternate between those two depending on runtime conditions ("releasing Zalgo"). Similar considerations led to the decision that `await` should always be asynchronous, even if passed a non-Promise.
 
-Note, this is an observable change from current ES Module semantics, where the Evaluate phase is entirely synchronous. For a concrete example and further discussion, see [issue #43](https://github.com/tc39/proposal-top-level-await/issues/43)
+To avoid reordering the execution of modules due to job queue activity, when there is no need to wait on a not-yet-resolved module, the job queue is run to completion after loading a module.
+
+Note, this is an observable change from current ES Module semantics, where the Evaluate phase is entirely synchronous. For a concrete example and further discussion, see [issue #43](https://github.com/tc39/proposal-top-level-await/issues/43) and [#47](https://github.com/tc39/proposal-top-level-await/issues/47).
 
 #### Does top-level `await` increase the risk of deadlocks?
 

spec.html

@@ -370,11 +370,9 @@ <h1>InnerModuleEvaluation( _module_, _stack_, _index_ )</h1>
           1. If _requiredModule_.[[Status]] is `"evaluating"`, then
             1. Assert: _requiredModule_ is a Source Text Module Record.
             1. Set _module_.[[DFSAncestorIndex]] to min(_module_.[[DFSAncestorIndex]], _requiredModule_.[[DFSAncestorIndex]]).
-            1. <ins>Let _stackErrorCapability_ be ! NewPromiseCapability(%Promise%).</ins>
-            1. <ins>Perform ! PerformPromiseThen(_requiredModule_.[[ExecPromise]], *undefined*, _stackErrorCapability_.[[Reject]]).</ins>
-            1. <ins>Add _stackErrorCapability_ to the list _dependencyExecPromises_.</ins>
         1. <del>Perform ? ModuleExecution(_module_).</del>
         1. <ins>Perform ! ExecuteModuleWhenImportsReady(_module_, _dependencyExecPromises_, _evalCapability_).</ins>
+        1. <ins>Perform ! FlushJobs().</ins>
         1. Assert: _module_ occurs exactly once in _stack_.
         1. Assert: _module_.[[DFSAncestorIndex]] is less than or equal to _module_.[[DFSIndex]].
         1. If _module_.[[DFSAncestorIndex]] equals _module_.[[DFSIndex]], then
@@ -384,6 +382,7 @@ <h1>InnerModuleEvaluation( _module_, _stack_, _index_ )</h1>
             1. Remove the last element of _stack_.
             1. Set _requiredModule_.[[Status]] to `"evaluated"`.
             1. If _requiredModule_ and _module_ are the same Module Record, set _done_ to *true*.
+            1. <ins>Otherwise, set _requiredModule_.[[ExecPromise]] to _module_.[[ExecPromise]].</ins>
         1. Return _index_.
       </emu-alg>
       <emu-note>
@@ -508,6 +507,20 @@ <h1>Runtime Semantics: TopLevelModuleEvaluationJob ( _sourceText_, _hostDefined_
       <p>An implementation may parse a _sourceText_ as a |Module|, analyse it for Early Error conditions, and instantiate it prior to the execution of the TopLevelModuleEvaluationJob for that _sourceText_. An implementation may also resolve, pre-parse and pre-analyse, and pre-instantiate module dependencies of _sourceText_. However, the reporting of any errors detected by these actions must be deferred until the TopLevelModuleEvaluationJob is actually executed.</p>
     </emu-note>
   </emu-clause>
+
+  <emu-clause id="sec-flushjobs" aoid="FlushJobs">
+    <h1>FlushJobs ( )</h1>
+    <emu-alg>
+      1. Assert: There is no running execution context.
+      1. Yield control to the RunJobs algorithm.
+      1. When RunJobs has no more jobs to run, return from this algorithm.
+    </emu-alg>
+    <emu-note type=editor>
+      <p>This algorithm completes asynchronously, but is to be used synchronously within a larger ECMAScript algorithm. For this reason, it may only be called when there is no running execution context.</p>
+      <p>HTML and ECMAScript have different notions of how the Job Queue works, with HTML employing a willful violation to describe the layering; see <a href="https://html.spec.whatwg.org/#integration-with-the-javascript-job-queue">Integration with the JavaScript job queue</a> for details.See <a href="https://github.com/tc39/ecma262/pull/735">#735</a> for one approach to improving the layering. Until some kind of fix in this area occurs, this proposal sticks with the "willful violation" layering approach.</p>
+      <p>In the HTML context, the FlushJobs() algorithm would be replaced, via a willful violation, with the <a href="https://html.spec.whatwg.org/#perform-a-microtask-checkpoint">perform a microtask checkpoint</a> algorithm</p>
+    </emu-note>
+  </emu-clause>
 </emu-clause>
 
 <emu-clause id="sec-modules">