Implement Async Functions #692

bterlson · 2016-09-15T21:09:39Z

This PR implements async functions as specified in the Async Functions Proposal with minor modifications. This is a big PR with lots of fiddly pieces. As such, I'm sure there are minor editorial and likely technical issues.

To aid in reviewing, I've published a build of the spec with async funtions. Below is a list of changes with deep links. Please help me review this!

Updates to Table 7 to add %AsyncFunction% and %AsyncFunctionPrototype%. Table 7
Updated note in 10.2 about types of source code 10.2
await is a new keyword 11.6.2.1
await added as alternative for various Identifier kinds 12.1 and appropriate early errors 12.1.1.
New language for applying supplemental grammars that doesn't require permuting the various combinations of parameter values 12.2.1.1 and other examples.
Xref for async function expression 12.2.7
Add cover grammar for CallExpression
New supplemental syntax for CallExpression: CallMemberExpression
Static semantics for pulling out the covered call member expression: 12.3.1.1
Updated function call evaluation semantics to apply cover grammar: 12.3.4.1
Updated assignment expression static semantics IsFunctionDefinition: 12.15.2
AsyncFunctionDeclaration to HoistableDeclaration (plus static semantics for same)
New lookahead for ExpressionStatement
New Early Error for arrow parameters to always disallow await 14.2.1
New clause Async Function Definitions.
New expression positions to the tail position calls spec 14.8.2.2
New lookahead in export default 15.2.3
Updates to CreateDynamicFunction to allow dynamic creation of async functions 19.2.1.1.1.
New clause Async Function Objects
New productions added to Annex A.2 and A.3

Additionally, any production of the grammar that took a yield parameter now also takes an await parameter. An RHS non-terminal that previously passed a ?Yield parameter now also pass ?Await. RHSes that passed +Yield or ~~Yield were updated to pass +/~~/?Await as appropriate.

bterlson · 2016-09-15T21:10:13Z

Accidentally submitted (still working on the TOC)...

bterlson · 2016-09-15T21:32:19Z

Ok good to go!

bterlson · 2016-09-15T21:59:01Z

Added changes to evalute body: removed first steps from https://bterlson.github.io/ecma262/#sec-ordinarycallevaluatebody and moved to corresponding EvaluateBodys (eg. https://bterlson.github.io/ecma262/#sec-function-definitions-runtime-semantics-evaluatebody). Rationale in this note.

domenic · 2016-09-15T23:01:10Z

Consider moving CreateDynamicFunction somewhere else, as it's now being used from multiple places and it's less appropriate to nest it under Function. On the other hand, I can't find any good place to put it.

I think the section "Async Function Objects" should be consistent with "GeneratorFunction Objects", i.e. space or no space.

domenic · 2016-09-15T23:08:18Z

"Note: Async functions are not constructable and do not have a prototype property." seems to contradict the line above it where you say "Else [if not a generator], perform MakeConstructor(F)".

domenic · 2016-09-15T23:09:14Z

The note below also would need adjusting: "A prototype property is automatically created for every function created using CreateDynamicFunction, to provide for the possibility that the function will be used as a constructor."

bterlson · 2016-09-15T23:16:15Z

"Note: Async functions are not constructable and do not have a prototype property." seems to contradict the line above it where you say "Else [if not a generator], perform MakeConstructor(F)".

Indeed! I put the note but didn't fix up the else leg. Will fix that plus the note.

littledan · 2016-09-16T00:08:46Z

Minor issue I noticed in debugging our async/await implementation: in https://bterlson.github.io/ecma262/#abstract-ops-async-function-await , you have to set throwawayCapability.[[Promise]].[[PromiseIsHandled]] to true.

domenic · 2016-09-16T00:38:23Z

It would be really nice if you could factor out a version of PerformPromiseThen which did not need to deal with the throwawayCapability business. It's shown up in multiple specs now. I think the idea would be to let the [[Capability]] field of PromiseReaction be undefined (noting that this is for spec-internal situations), add a check in PromiseReactionJob, and tweak PerformPromiseThen so that promiseCapability is an optional argument that defaults to undefined (i.e. change the assert and return value).

littledan · 2016-09-16T04:11:39Z

@domenic I think such a refactoring could be left to a later patch.

bterlson · 2016-09-16T16:52:01Z

@domenic yeah I'm leaning toward a separate refactoring patch for that. Can you open an issue on it (hopefully with an example I can take a look at)?

domenic · 2016-09-16T18:03:13Z

<a href="#async-function-definitions-awaited-fulfilled">AsyncFunction Awaited Fulfilled</a>

this should use emu-xref instead like the other closures do.

domenic · 2016-09-16T18:13:48Z

Function _F_ is called with the parameter _value_.

this is very terse compared to existing closure declarations, and should probably be expanded to be more like those (intro paragraph, internal slot list, when called, length specifier).

domenic · 2016-09-16T18:14:37Z

Also the section header should include "Functions"

domenic · 2016-09-16T18:16:27Z

Let _asyncContext_ be the value of _F_'s [[AsyncContext]] internal slot.

per recent changes, should be "Let asyncContext be F.[[AsyncContext]]". I'd suggest doing a search for "the value of" to find other instances.

domenic · 2016-09-16T18:51:36Z

In reviewing this further, I think the last steps of AsyncFunction Awaited Fulfilled/Rejected, where it returns the completion value, do not make much sense. It's not returning to anyone interesting; it would only impact the throwawayCapability.[[Promise]], which is, well, a throwaway.

bterlson · 2016-09-16T20:11:46Z

Note to self: I also need to define the [[AsyncContext]] internal slot somewhere.

domenic · 2016-09-16T20:28:49Z

This spec has not been updated for the great uppercasing of record fields. In particular completion record [[value]], [[target]], and [[type]] are all now uppercase.

…romises This patch implements a bug fix to the async/await specification described at tc39/ecma262#692 (comment) Namely, the intermediate values of Promises may be rejected, and they do not have .then called on them anymore (now that the memory leak is fixed), but they do not correspond do unhandled rejections. This change has been tested manually with integration with Blink; once it is checked in and rolled, then further tests can be added on the Blink side for the uncaught rejection handler and async/await. BUG=v8:4483 Review-Url: https://codereview.chromium.org/2338273007 Cr-Commit-Position: refs/heads/master@{#39480}

jmdyck

I have editorial tweaks, but I don't know how to submit a PR to a PR.

bterlson · 2016-09-17T16:12:08Z

@jmdyck: send the PR to this repo + branch: https://github.com/bterlson/ecma262/tree/async-functions. Then once the PR is accepted there it will show up here.

bterlson · 2016-09-17T16:12:40Z

Alternatively you can just push your fixes someplace and I can pull them in outside of the GitHub interface. Whichever is easiest for you!

bterlson · 2016-09-17T16:20:55Z

@jmdyck are your commits already ready to go? If so I can wait a bit before making further changes so as not to create rebase headaches...

jmdyck · 2016-09-17T17:55:27Z

I've just finished making all the changes on my local branch, but I haven't started doing any commits yet. If you've got stuff ready to push, you should probably just push it, and I'll deal with the headaches.

In order to submit a PR against your repo, I'd have to have a fork of it on github, right? But jmdyck/ecma262 already exists as a fork of tc39/ecma262, so I'm not sure how I could have another fork of ecma262.

bterlson · 2016-09-17T17:58:00Z

I also don't have commits yet, just started on the rest of Domenic's issues. I'll probably want to push something later today.

If you already have a fork, easiest way using the GitHub UI is to push your commits and hit the pull request button on your repo. On the next screen you can change the "base fork" to bterlson/ecma262 and base branch to async-functions, then create the PR.

jmdyck · 2016-09-17T22:40:35Z

Okay, I've finished all my commits. I'll see if I can make a PR.

…to true in AsyncFunctionAwait

bterlson · 2016-11-10T21:06:35Z

@littledan Right, added that plus the definition of [[AsyncContext]].

littledan · 2016-11-11T03:06:57Z

LGTM (AFAICT!)

not-an-aardvark · 2016-11-11T08:37:12Z

Editorial nit: I think section 19.2.1 will no longer be accurate after this is merged.

There is no syntactic means to create instances of Function subclasses except for the built-in GeneratorFunction subclass.

Maybe that section should mention AsyncFunction as well.

bterlson · 2016-11-11T17:58:37Z

@not-an-aardvark you are correct, I will fix that up!

…ctor

bterlson · 2016-11-11T22:18:33Z

Alright, gonna pull this in now. We can of course make further updates up 'til we freeze for ES2017.

The nonterminals: - FunctionExpression - ClassExpression - GeneratorExpression - AsyncGeneratorExpression are all defined with a single RHS involving an optional BindingIdentifier. But AsyncFunctionExpression is defined with two RHSs, one with a BindingIdentifier and one without. (It's been that way since it was introduced in PR tc39#692.) I can't see any reason for it to be not like the others.

The nonterminals: - FunctionExpression - ClassExpression - GeneratorExpression - AsyncGeneratorExpression are all defined with a single RHS involving an optional BindingIdentifier. But AsyncFunctionExpression is defined with two RHSs, one with a BindingIdentifier and one without. (It's been that way since it was introduced in PR tc39#692) I can't see any reason for it to be not like the others.

alkthegit · 2024-05-07T03:23:50Z

Hi there,

I'm curious about why the link up there is not working anymore: https://tc39.github.io/ecmascript-asyncawait

Hope that doesn't mean the proposal was somehow reverted from the ES spec :)
So, where can I read the text of that original proposal for the purpose of learning?

ctcpip · 2024-05-07T03:40:28Z

@alkthegit https://github.com/tc39/proposal-async-await

and that same content rendered available here as well: https://web.archive.org/web/20201113005044/https://tc39.es/ecmascript-asyncawait/

alkthegit · 2024-05-07T03:50:03Z

Thanks, but I've already been there and the page also contains the same broken link.

What I was hoping to find is a kind of a "long explaner", with an example being here on the pipe operator:
https://github.com/tc39/proposal-pipeline-operator

Thought it was moved to the resource under the broken link but maybe it just never existed?

ljharb · 2024-05-07T03:51:36Z

Indeed the proposal repo, and https://tc39.es/proposal-async-await/, are all that exists. Not every proposal chooses the same ways to explain itself.

alkthegit · 2024-05-07T03:53:25Z

Ok, got it.
Seems like maybe there is little to be "long explained" :).

ctcpip · 2024-05-07T03:57:43Z

@alkthegit you may be interested in presentations and discussions from meetings, e.g.

https://github.com/tc39/notes/blob/HEAD/meetings/2014-01/jan-30.md?plain=1#L164
https://github.com/tc39/notes/blob/HEAD/meetings/2014-04/apr-10.md?plain=1#L785
https://github.com/tc39/notes/blob/HEAD/meetings/2015-07/july-30.md?plain=1#L170
https://github.com/tc39/notes/blob/HEAD/meetings/2016-07/jul-28.md?plain=1#L1017

alkthegit · 2024-05-07T04:04:08Z

Thanks, Chris!
I'll take a glance at it.
Can't see your link here but received it via email notify.

ctcpip · 2024-05-07T04:05:22Z

it was the wrong link. updated above. there are others, at least one more, but that's what I was able to find quickly

bterlson force-pushed the async-functions branch from 314761c to 9db23b2 Compare September 15, 2016 21:30

domenic mentioned this pull request Sep 15, 2016

"Runtime Semantics: EvaluateBody" seems inconsistent with the existing spec tc39/proposal-async-iteration#27

Closed

domenic mentioned this pull request Sep 15, 2016

Rebase CreateDynamicFunction after it gets fixed tc39/proposal-async-iteration#46

Closed

domenic mentioned this pull request Sep 16, 2016

Spec factoring: allow PerformPromiseThen with no capability #694

Closed

jmdyck reviewed Sep 16, 2016

View reviewed changes

bterlson added 2 commits November 9, 2016 15:25

Editorial: describe [[AsyncContext]] slot

b059c4f

Normative: Set throwawayPromiseCapability promise's PromiseIsHandled …

14886ee

…to true in AsyncFunctionAwait

Editorial: mention async function constructor in sec-function-constru…

261aaf8

…ctor

bterlson merged commit 869f1c6 into tc39:master Nov 11, 2016

This was referenced Nov 12, 2016

Add support for experimental configuration jshint/jshint#2601

Open

Support for async functions jshint/jshint#2604

Closed

ljharb mentioned this pull request Nov 16, 2016

Editorial: Remove duplicate GeneratorPrototype mention #734

Merged

jugglinmike mentioned this pull request Nov 23, 2016

Editorial: Re-factor ExportSpecifier #637

Merged

domenic mentioned this pull request Dec 9, 2016

CreateDynamicFunction is not correct for async function prototypes #751

Closed

jmdyck mentioned this pull request Dec 31, 2019

CreateImmutableBinding called with only one argument #1824

Closed

jmdyck mentioned this pull request Jan 14, 2021

Editorial: Merge the RHSs of AsyncFunctionExpression #2275

Merged

jmdyck mentioned this pull request Mar 17, 2021

Editorial: Eliminate CoveredFoo SDOs #2350

Merged

jmdyck mentioned this pull request Jan 3, 2022

Editorial: missing syntax error (involving CoverCallExpressionAndAsyncArrowHead) #2607

Open

jmdyck mentioned this pull request Aug 13, 2024

Editorial: Eliminate order-disambiguation from Annex B Pattern-grammar #2445

Open

Implement Async Functions #692

Implement Async Functions #692

Conversation

bterlson commented Sep 15, 2016 • edited Loading

bterlson commented Sep 15, 2016

bterlson commented Sep 15, 2016

bterlson commented Sep 15, 2016 • edited Loading

domenic commented Sep 15, 2016

domenic commented Sep 15, 2016

domenic commented Sep 15, 2016

bterlson commented Sep 15, 2016

littledan commented Sep 16, 2016

domenic commented Sep 16, 2016

littledan commented Sep 16, 2016

bterlson commented Sep 16, 2016

domenic commented Sep 16, 2016

domenic commented Sep 16, 2016

domenic commented Sep 16, 2016

domenic commented Sep 16, 2016

domenic commented Sep 16, 2016

bterlson commented Sep 16, 2016

domenic commented Sep 16, 2016

jmdyck left a comment

Choose a reason for hiding this comment

bterlson commented Sep 17, 2016

bterlson commented Sep 17, 2016

bterlson commented Sep 17, 2016

jmdyck commented Sep 17, 2016

bterlson commented Sep 17, 2016 • edited Loading

jmdyck commented Sep 17, 2016

bterlson commented Nov 10, 2016

littledan commented Nov 11, 2016

not-an-aardvark commented Nov 11, 2016

bterlson commented Nov 11, 2016

bterlson commented Nov 11, 2016

alkthegit commented May 7, 2024 • edited Loading

ctcpip commented May 7, 2024 • edited Loading

alkthegit commented May 7, 2024

ljharb commented May 7, 2024

alkthegit commented May 7, 2024

ctcpip commented May 7, 2024 • edited Loading

alkthegit commented May 7, 2024

ctcpip commented May 7, 2024 • edited Loading

bterlson commented Sep 15, 2016 •

edited

Loading

bterlson commented Sep 15, 2016 •

edited

Loading

bterlson commented Sep 17, 2016 •

edited

Loading

alkthegit commented May 7, 2024 •

edited

Loading

ctcpip commented May 7, 2024 •

edited

Loading

ctcpip commented May 7, 2024 •

edited

Loading

ctcpip commented May 7, 2024 •

edited

Loading