Skip to content

Commit

Permalink
Editorial: pull in ecmarkup reduced-width document styles (tc39#3277)
Browse files Browse the repository at this point in the history
  • Loading branch information
@michaelficarra @ljharb
michaelficarra authored and ljharb committed Feb 5, 2024
1 parent ab3e577 commit 3a773fc
Showing 1 changed file with 11 additions and 21 deletions.
32 changes: 11 additions & 21 deletions spec.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -40,16 +40,6 @@
width: 100%;
font-size: 80%;
}

.module-overflow {
overflow-y: scroll;
display: block;
}

.module-overflow-note {
overflow-y: scroll;
}

</style>
<pre class="metadata">
title: ECMAScript&reg; 2024 Language&nbsp;Specification
Expand Down Expand Up @@ -27020,7 +27010,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Calling _A_.Evaluate() calls InnerModuleEvaluation on _A_, _B_, and _D_, which all transition to ~evaluating~. Then InnerModuleEvaluation is called on _A_ again, which is a no-op because it is already ~evaluating~. At this point, _D_.[[PendingAsyncDependencies]] is 0, so ExecuteAsyncModule(_D_) is called and we call _D_.ExecuteModule with a new PromiseCapability tracking the asynchronous execution of _D_. We unwind back to the InnerModuleEvaluation on _B_, setting _B_.[[PendingAsyncDependencies]] to 1 and _B_.[[AsyncEvaluation]] to *true*. We unwind back to the original InnerModuleEvaluation on _A_, setting _A_.[[PendingAsyncDependencies]] to 1. In the next iteration of the loop over _A_'s dependencies, we call InnerModuleEvaluation on _C_ and thus on _D_ (again a no-op) and _E_. As _E_ has no dependencies and is not part of a cycle, we call ExecuteAsyncModule(_E_) in the same manner as _D_ and _E_ is immediately removed from the stack. We unwind once more to the original InnerModuleEvaluation on _A_, setting _C_.[[AsyncEvaluation]] to *true*. Now we finish the loop over _A_'s dependencies, set _A_.[[AsyncEvaluation]] to *true*, and remove the entire strongly connected component from the stack, transitioning all of the modules to ~evaluating-async~ at once. At this point, the fields of the modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-1"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-1" class="module-overflow" caption="Module fields after the initial Evaluate() call">
<emu-table id="table-module-graph-cycle-async-fields-1" caption="Module fields after the initial Evaluate() call">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27083,7 +27073,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Let us assume that _E_ finishes executing first. When that happens, AsyncModuleExecutionFulfilled is called, _E_.[[Status]] is set to ~evaluated~ and _C_.[[PendingAsyncDependencies]] is decremented to become 1. The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-2"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-2" class="module-overflow" caption="Module fields after module _E_ finishes executing">
<emu-table id="table-module-graph-cycle-async-fields-2" caption="Module fields after module _E_ finishes executing">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27119,7 +27109,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>_D_ is next to finish (as it was the only module that was still executing). When that happens, AsyncModuleExecutionFulfilled is called again and _D_.[[Status]] is set to ~evaluated~. Then _B_.[[PendingAsyncDependencies]] is decremented to become 0, ExecuteAsyncModule is called on _B_, and it starts executing. _C_.[[PendingAsyncDependencies]] is also decremented to become 0, and _C_ starts executing (potentially in parallel to _B_ if _B_ contains an `await`). The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-3"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-3" class="module-overflow" caption="Module fields after module _D_ finishes executing">
<emu-table id="table-module-graph-cycle-async-fields-3" caption="Module fields after module _D_ finishes executing">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27164,7 +27154,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Let us assume that _C_ finishes executing next. When that happens, AsyncModuleExecutionFulfilled is called again, _C_.[[Status]] is set to ~evaluated~ and _A_.[[PendingAsyncDependencies]] is decremented to become 1. The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-4"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-4" class="module-overflow" caption="Module fields after module _C_ finishes executing">
<emu-table id="table-module-graph-cycle-async-fields-4" caption="Module fields after module _C_ finishes executing">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27200,7 +27190,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Then, _B_ finishes executing. When that happens, AsyncModuleExecutionFulfilled is called again and _B_.[[Status]] is set to ~evaluated~. _A_.[[PendingAsyncDependencies]] is decremented to become 0, so ExecuteAsyncModule is called and it starts executing. The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-5"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-5" class="module-overflow" caption="Module fields after module _B_ finishes executing">
<emu-table id="table-module-graph-cycle-async-fields-5" caption="Module fields after module _B_ finishes executing">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27236,7 +27226,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Finally, _A_ finishes executing. When that happens, AsyncModuleExecutionFulfilled is called again and _A_.[[Status]] is set to ~evaluated~. At this point, the Promise in _A_.[[TopLevelCapability]] (which was returned from _A_.Evaluate()) is resolved, and this concludes the handling of this module graph. The fields of the updated module are as given in <emu-xref href="#table-module-graph-cycle-async-fields-6"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-6" class="module-overflow" caption="Module fields after module _A_ finishes executing">
<emu-table id="table-module-graph-cycle-async-fields-6" caption="Module fields after module _A_ finishes executing">
<table>
<thead>
<tr>
Expand All @@ -27263,7 +27253,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Alternatively, consider a failure case where _C_ fails execution and returns an error before _B_ has finished executing. When that happens, AsyncModuleExecutionRejected is called, which sets _C_.[[Status]] to ~evaluated~ and _C_.[[EvaluationError]] to the error. It then propagates this error to all of the AsyncParentModules by performing AsyncModuleExecutionRejected on each of them. The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-7"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-7" class="module-overflow" caption="Module fields after module _C_ finishes with an error">
<emu-table id="table-module-graph-cycle-async-fields-7" caption="Module fields after module _C_ finishes with an error">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27302,7 +27292,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>_A_ will be rejected with the same error as _C_ since _C_ will call AsyncModuleExecutionRejected on _A_ with _C_'s error. _A_.[[Status]] is set to ~evaluated~. At this point the Promise in _A_.[[TopLevelCapability]] (which was returned from _A_.Evaluate()) is rejected. The fields of the updated module are as given in <emu-xref href="#table-module-graph-cycle-async-fields-8"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-8" class="module-overflow" caption="Module fields after module _A_ is rejected">
<emu-table id="table-module-graph-cycle-async-fields-8" caption="Module fields after module _A_ is rejected">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27331,7 +27321,7 @@ <h1>Example Cyclic Module Record Graphs</h1>

<p>Then, _B_ finishes executing without an error. When that happens, AsyncModuleExecutionFulfilled is called again and _B_.[[Status]] is set to ~evaluated~. GatherAvailableAncestors is called on _B_. However, _A_.[[CycleRoot]] is _A_ which has an evaluation error, so it will not be added to the returned _sortedExecList_ and AsyncModuleExecutionFulfilled will return without further processing. Any future importer of _B_ will resolve the rejection of _B_.[[CycleRoot]].[[EvaluationError]] from the evaluation error from _C_ that was set on the cycle root _A_. The fields of the updated modules are as given in <emu-xref href="#table-module-graph-cycle-async-fields-9"></emu-xref>.</p>

<emu-table id="table-module-graph-cycle-async-fields-9" class="module-overflow" caption="Module fields after module _B_ finishes executing in an erroring graph">
<emu-table id="table-module-graph-cycle-async-fields-9" caption="Module fields after module _B_ finishes executing in an erroring graph">
<table>
<thead>
<tr>
Expand Down Expand Up @@ -27519,7 +27509,7 @@ <h1>Source Text Module Records</h1>
</tr>
</table>
</emu-table>
<emu-note class="module-overflow-note">
<emu-note>
<p><emu-xref href="#table-import-forms-mapping-to-importentry-records"></emu-xref> gives examples of ImportEntry records fields used to represent the syntactic import forms:</p>
<emu-table id="table-import-forms-mapping-to-importentry-records" caption="Import Forms Mappings to ImportEntry Records" informative oldids="table-40">
<table>
Expand Down Expand Up @@ -27664,7 +27654,7 @@ <h1>Source Text Module Records</h1>
</tr>
</table>
</emu-table>
<emu-note class="module-overflow-note">
<emu-note>
<p><emu-xref href="#table-export-forms-mapping-to-exportentry-records"></emu-xref> gives examples of the ExportEntry record fields used to represent the syntactic export forms:</p>
<emu-table id="table-export-forms-mapping-to-exportentry-records" caption="Export Forms Mappings to ExportEntry Records" informative oldids="table-42">
<table>
Expand Down

0 comments on commit 3a773fc

Please sign in to comment.