Update async generator implementation to the latest spec
Categories
(Core :: JavaScript Engine, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox143 | --- | fixed |
People
(Reporter: arai, Assigned: arai)
References
(Blocks 1 open bug)
Details
Attachments
(17 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
In the same way as bug 1724123, we need to update the implementation to match the latest spec again.
Assignee | ||
Updated•23 days ago
|
Updated•22 days ago
|
Assignee | ||
Comment 1•22 days ago
|
||
Assignee | ||
Comment 2•22 days ago
|
||
Handling the special states is not AsyncGeneratorDrainQueue's responsibility,
and also some consumers already filter out those states.
Assignee | ||
Comment 3•22 days ago
|
||
Assignee | ||
Comment 4•22 days ago
|
||
"completed" state has two separate internal states.
One is where there's no request in the queue.
This maps to the updated spec's "completed" state.
The other is where there are some requests in the queue, and those requests
are going to be drained in upcoming AsyncGeneratorDrainQueue.
This maps to the updated spec's "draining-queue" state.
In the former case, if .next/.throw/.return is called, a new request for them
will be immediately processed.
In the latter case, if .next/.throw/.return is called before draining the
existing requests, which means those calls are performed inside
AsyncGeneratorDrainQueue, as a side-effect of promise handling.
Those calls will enqueue the request and then perform another
AsyncGeneratorDrainQueue, and all requests will be processed there.
This is actually the same situation as just enqueueing and not performing
another AsyncGeneratorDrainQueue. The next patch will remove the
AsyncGeneratorDrainQueue call.
Assignee | ||
Comment 5•22 days ago
|
||
The AsyncGeneratorDrainQueue call for the completed+non-empty-queue happens
only as a part of side-effect of promise handling which is performed
during AsyncGeneratorDrainQueue.
The requests will be handled by the outer AsyncGeneratorDrainQueue.
Assignee | ||
Comment 6•22 days ago
|
||
This patch just inlines the AsyncGeneratorDrainQueue code to each consumer,
with slight modification for the return
statements.
The subsequent patches will simplify each case.
Assignee | ||
Comment 7•22 days ago
|
||
Each consumer has specific situation, where the loop and some branches can be
removed.
Assignee | ||
Comment 8•22 days ago
|
||
This is unobservable change.
This makes the else-branch match the updated spec.
The then-branch's state transition is not part of the spec, but the state
will be overwritten immediately.
Assignee | ||
Comment 9•22 days ago
|
||
This makes one of AsyncGeneratorUnwrapYieldResumption consumer to match the
updated spec.
The other consumer will be rewritten in later patch.
Assignee | ||
Comment 10•22 days ago
|
||
Assignee | ||
Comment 11•22 days ago
|
||
The state is going to immediately be overwritten to either:
- AwaitingYieldReturn if completionKind is Return, or
- Executing otherwise
Assignee | ||
Comment 12•22 days ago
|
||
The request enqueued in the "Completed+empty-queue" case will be immediately
dequeued and processed.
This patch removes the queue+dequeue and let each case directly pass the
completeion.
Assignee | ||
Comment 13•22 days ago
|
||
This is another consumer of AsyncGeneratorUnwrapYieldResumption,
which is added in earlier patch.
Assignee | ||
Comment 14•22 days ago
|
||
Assignee | ||
Comment 15•22 days ago
|
||
Now all consumers of AsyncGeneratorDrainQueue sets the state to "completed"
before entering AsyncGeneratorDrainQueue, and
"suspended-start" and "suspended-yield" states don't reach there,
even with side-effects.
Assignee | ||
Comment 16•22 days ago
|
||
This modifies the existing states in the following ways:
- Completed (empty queue) -> Completed
- Completed (non-empty queue) -> DrainingQueue
- AwaitingYieldReturn -> Executing_AwaitingYieldReturn
- AwaitingReturn -> DrainingQueue_AwaitingReturn
The latter 2 are not part of the updated spec, but they're our
implementation-defined state, to reflect the state during the Await
calls.
Assignee | ||
Comment 17•22 days ago
|
||
Comment 18•21 days ago
|
||
Comment 19•21 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/e16f2e94fafb
https://hg.mozilla.org/mozilla-central/rev/d41df4292f15
https://hg.mozilla.org/mozilla-central/rev/3777ca63a7d2
https://hg.mozilla.org/mozilla-central/rev/a381c7ee6bf3
https://hg.mozilla.org/mozilla-central/rev/93f5b5332d86
https://hg.mozilla.org/mozilla-central/rev/9044d687cf06
https://hg.mozilla.org/mozilla-central/rev/69a84ced2945
https://hg.mozilla.org/mozilla-central/rev/13b3d1aadb36
https://hg.mozilla.org/mozilla-central/rev/b1a0f12ba781
https://hg.mozilla.org/mozilla-central/rev/0670b4a44063
https://hg.mozilla.org/mozilla-central/rev/aafd77ab2a2c
https://hg.mozilla.org/mozilla-central/rev/ff097c4cc4de
https://hg.mozilla.org/mozilla-central/rev/b36d99d371a1
https://hg.mozilla.org/mozilla-central/rev/70a42de5f414
https://hg.mozilla.org/mozilla-central/rev/75536f7a0080
https://hg.mozilla.org/mozilla-central/rev/ce5019292a43
https://hg.mozilla.org/mozilla-central/rev/940a04fd8ade
Description
•