Closed Bug 1317379 Opened 8 years ago Closed 8 years ago

B.3.4 shouldn't be applied for generator and async functions

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla53
Tracking Status
firefox52 --- wontfix
firefox53 --- fixed

People

(Reporter: anba, Assigned: Waldo)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

`if (true) function* g() {}` and `if (true) async function f() {}` should both throw a SyntaxError because B.3.4 only applies for FunctionDeclaration. ES2017 spec: https://tc39.github.io/ecma262/#sec-functiondeclarations-in-ifstatement-statement-clauses
Assignee: nobody → jwalden+bmo
Status: NEW → ASSIGNED
Comment on attachment 8810674 [details] [diff] [review] Disallow generator functions and async functions as direct children of if/else Review of attachment 8810674 [details] [diff] [review]: ----------------------------------------------------------------- Thanks!
Attachment #8810674 - Flags: review?(arai.unmht) → review+
Pushed by jwalden@mit.edu: https://hg.mozilla.org/integration/mozilla-inbound/rev/4c223c3ddf73 Disallow generator functions and async functions as direct children of if/else. r=arai
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Sorry about all these requests. Not sure if it will work to backport everything. Let us at least try to backport the easy / lowest risk ones. I also assume that all these issues probably go back before F52? Though I don't think we can / need to backport to beta. I assume only serious security issues are allowed currently.
Flags: needinfo?(andrebargull)
I think Waldo should decide if it's safe to backport this one.
Flags: needinfo?(andrebargull) → needinfo?(jwalden+bmo)
I can't think of a reason why we'd need to backport this. It's enough of an edge case that I doubt anyone will come to depend on this bugginess, and that seems like the only reason to accelerate a fix. Even if we did decide this was important to fix earlier, the changes span sufficient number of lines, and are picky enough about peeking and lookahead and such, that it presents *some* risk of containing a mistake. And when there's not much to gain, some risk is too much risk. I say we don't even consider taking this.
Flags: needinfo?(jwalden+bmo)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: