-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Normative: Treat IterationStatements uniformly in Annex B.3.5. #1393
Conversation
Are there any other cases? I'm not sure the bolded part of this rule is ever unsatisfied. |
I think you're right, since function declarations add to a block's LexicallyDeclaredNames and not to its VarDeclaredNames. I'm a bit confused about what this implies for the second instance though. Technically, what's written there is not exhaustive—if it read HoistableDeclaration instead of FunctionDeclaration, then we could delete the entire sentence, but as it stands it would not allow, e.g., GeneratorDeclaration. However, it appears that not a single engine actually distinguishes among HoistableDeclarations here! // SyntaxError in V8, SM, XS; permitted in JSC, CH
try {} catch (e) { function e() {} }
try {} catch (e) { function* e() {} }
try {} catch (e) { async function e() {} }
try {} catch (e) { async function* e() {} }
// permitted in V8, SM, CH; SyntaxError in JSC, XS
try { throw 1; } catch (e) { eval('function e() {}'); }
try { throw 1; } catch (e) { eval('function* e() {}'); }
try { throw 1; } catch (e) { eval('async function e() {}'); }
try { throw 1; } catch (e) { eval('async function* e() {}'); }
// (Side note: CH doesn't actually have async generators right now.) So perhaps web reality suggests that we could do away with that whole sentence after all? 🤔 |
Your example gives rise to another piece of esoterica: currently Annex B.3.3 interaction with B.3.5 means the following, which may or may not be surprising to you depending on how long you've stared at the abyss: function foo() { try { throw 1; } catch (e) { { function e() {} } } print(e); }
foo() // prints "function e() {}" but function bar() { try { throw 1; } catch (e) { function e() {} } print(e); } // SyntaxError |
@syg Thankfully though, that too applies equally to the four HoistableDeclaration types. 😄 |
Made @bakkot's suggested simplification as well as the web reality simplification from #1393 (comment). |
Implementation status, just for the record: |
@rkirsling Are you gonna patch Test262 as well? |
@mathiasbynens tc39/test262#2023 is just awaiting the green button. 😄 |
Tests merged, two implementations landed. 🎊 |
…and now it landed in SpiderMonkey as well! |
This patch changes the parser to allow for-of initializer var-redeclaration of non-destructured catch parameters. Previously, the spec allowed var-redeclaration of a non-destructured catch parameter… try {} catch (e) { var e; } …except in the particular case where the var declaration is a for-of initializer: try {} catch (e) { for (var e of whatever) {} } tc39/ecma262#1393 removes this strange exceptional case. This patch implements that change. BUG=v8:8759 Change-Id: Ia4e33ac1eab89085f8a5fdb547f479cfa38bbee5 Reviewed-on: https://chromium-review.googlesource.com/c/1444954 Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#59209}
7c64563
to
8a16cb8
Compare
Resolves #1392.