Async functions and await expressions #446
Conversation
mysticatea
force-pushed
the
asyncawait
branch
6 times, most recently
from
e79ed22
to
607f0e0
Compare
|
I think I have finished the implementation of async/await for the normal parser of Acorn. If Acorn will support the new stage 4 feature, I'm happy if you review this PR. |
|
I have done implementing for the loose parser. |
mysticatea
changed the title
|
@marijnh @RReverser Could you reply any response, please? |
| this.parsePropertyName(prop) | ||
| this.parsePropertyValue(prop, isPattern, isGenerator, startPos, startLoc, refDestructuringErrors) | ||
| this.parsePropertyName(prop, refDestructuringErrors) | ||
| if (!isPattern && this.options.ecmaVersion >= 8 && !isGenerator && !prop.computed && prop.key.type === "Identifier" && prop.key.name === "async" && (this.type === tt.name || this.type === tt.bracketL) && !this.canInsertSemicolon()) { |
There was a problem hiding this comment.
this.type === tt.name || this.type === tt.bracketL
This doesn't seem quite sufficient; according to the spec, async methods can have arbitrary PropertyNames as their name, so the following should probably be allowed:
({
async "m"() {},
async 42() {}
})There was a problem hiding this comment.
Oh, good catch. Thank you!
There was a problem hiding this comment.
I replaced the condition by this.type !== tt.parenL.
Thank you!
|
I tweaked the history of this PR to make reviewing easy. |
| @@ -71,7 +71,7 @@ export class Parser { | |||
| this.potentialArrowAt = -1 | |||
|
|
|||
| // Flags to track whether we are in a function, a generator. | |||
There was a problem hiding this comment.
Add ", an async function"
|
I fixed the taught problem. |
|
@marijnh @RReverser Could you tell me what I should do to advance this PR? I will do accordingly. |
| node.computed = true | ||
| this.expect(tt.bracketR) | ||
| base = this.finishNode(node, "MemberExpression") | ||
| } else if (!noCalls && this.eat(tt.parenL)) { | ||
| let refDestructuringErrors = new DestructuringErrors | ||
| let exprList = this.parseExprList(tt.parenR, false, false, refDestructuringErrors) | ||
| if (maybeAsyncArrow && !this.canInsertSemicolon() && this.eat(tt.arrow)) { |
There was a problem hiding this comment.
I don't think it is possible for maybeAsyncArrow to be true (which depends on base.name == "async") and this branch, whose conditional uses this.eat(tt.parentL), to also be taken, since both would be referring to the same token, which can't both be async and (. Am I missing something?
There was a problem hiding this comment.
Argh, never mind, the original expression is inspecting the node, not the token state. Ignore me.
|
I've merged this as c3cac9c...7304648 and followed up with some small patches 7304648...78e8aa7. Please take a look at those and see if you agree. I'm not very happy with the further complexity around the |
|
(I should add that my benchmarks don't notice a measurable slowdown due to those extra error-tracking objects that are allocated.) |
|
@marijnh Small short-lived objects are allocated from a "fast storage" in most modern engine GCs, so at least performance-wise it shouldn't be a problem. |
|
@RReverser That's true, but such objects aren't free -- they'll still cause more minor GCs to happen, which has a cost. |
|
@marijnh Unless an optimizer detects that those objects can be used directly from the stack. Although this is implementation-dependant and probably not something to be relied upon (as well as any performance guesses). |
|
What's a plan for release? |
See this. |
Async functions proposal arrived stage 4.
I'm investigating to implement async/await.
This is work in progress, but I'm happy to be reviewed and asked any concerns.
If acorn will not consider accepting stage 4 features, please close this PR.