1788969 - Align async iterable code more closely with the spec

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Peter Van der Beken [:peterv]]

Currently the generated code relies on the native DOM classes to implement the whole algorithm for the next method in https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object, at least from step 8 to 12. That quite a complicated algorithm, and in practice the current example classes get a lot of it wrong! It also doesn't make sense to reimplement all the steps from that algorithm for every async iterable DOM class, the only real difference is the part that does "getting the next iteration result" (which is the part defined in every spec that has async iterables). Ideally that should be the only part that the native classes should implement.

Comment 1

[Peter Van der Beken [:peterv]]

Attachment: Bug 1788969 - Improve example code for async iterable. r?edgar!

Comment 2

[Peter Van der Beken [:peterv]]

Attachment: Bug 1788969 - Reject async iterable result promises on error instead of throwing. r?edgar!

Depends on D156320

Comment 3

[Peter Van der Beken [:peterv]]

Attachment: Bug 1788969 - Correct ForEach Tuple helper functions. r?kmag!

Depends on D156321

Comment 4

[Peter Van der Beken [:peterv]]

Attachment: Bug 1788969 - Align async iterable code more closely with the spec. r?edgar!

Implement the common steps for the next method from
https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object in
a base class, that all async iterable iterator objects inherit from. Natives
that implement an async iterable only need to implement the "getting the
next iteration result" part in their GetNextPromise method. This means they
don't have to create the object according to "CreateIterResultObject"
themselves, but can just create promise and often resolve it with a native
value directly. We've switched to a special JS::Value to signal "end of
iteration", but that's hidden inside the
iterator_utils::ResolvePromiseForFinished helper.
The WebIDL parser now uses the right return type for the generated "next"
method, which means that any exceptions in the binding code itself will
actually be correctmy converted to a rejected promise instead of being
rethrown.
This also uses a class for the generated iterable iterator that's not
exposed outside the binding code. No other code should create and/or
wrap these anyway.

Depends on D156322

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18b26912dc03
Improve example code for async iterable. r=edgar
https://hg.mozilla.org/integration/autoland/rev/d19caa9f062b
Reject async iterable result promises on error instead of throwing. r=edgar
https://hg.mozilla.org/integration/autoland/rev/edaf37ffc49d
Correct ForEach Tuple helper functions. r=glandium
https://hg.mozilla.org/integration/autoland/rev/56682c253427
Align async iterable code more closely with the spec. r=edgar

Comment 6

[Sandor Molnar[:smolnar]]

Backed out for causing bp-hybrid bustages.

Backout link: https://hg.mozilla.org/integration/autoland/rev/0413cf8b2fb959ca99a80af39b627b34611f020a

Push with failures

Failure log

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7071db6beede
Improve example code for async iterable. r=edgar
https://hg.mozilla.org/integration/autoland/rev/462f40755f80
Reject async iterable result promises on error instead of throwing. r=edgar
https://hg.mozilla.org/integration/autoland/rev/e127e2c70056
Correct ForEach Tuple helper functions. r=glandium
https://hg.mozilla.org/integration/autoland/rev/a6f9c1d6f2c9
Align async iterable code more closely with the spec. r=edgar

Comment 8

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/7071db6beede
https://hg.mozilla.org/mozilla-central/rev/462f40755f80
https://hg.mozilla.org/mozilla-central/rev/e127e2c70056
https://hg.mozilla.org/mozilla-central/rev/a6f9c1d6f2c9