Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: pull in ecmarkup reduced-width document styles #3277

Merged
merged 2 commits into from
Feb 5, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions package-lock.json

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion package.json
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@
"license": "SEE LICENSE IN https://tc39.es/ecma262/#sec-copyright-and-software-license",
"homepage": "https://tc39.es/ecma262/",
"dependencies": {
"ecmarkup": "^18.1.0"
"ecmarkup": "^18.1.3"
},
"devDependencies": {
"glob": "^7.1.6",
Expand Down
32 changes: 11 additions & 21 deletions spec.html
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
Loading