- 07 Sep, 2016 1 commit
-
-
marja authored
This moves scope-related logic (such as looking up variables) to Scope where it belongs, and enables PreParser to do more Scope-related operations in the future. BUG= Review-Url: https://codereview.chromium.org/2301183003 Cr-Commit-Position: refs/heads/master@{#39233}
-
- 14 Jul, 2016 1 commit
-
-
bakkot authored
Annex B.3.3 of the spec requires that sloppy-mode block-scoped functions declared by "eval" are hoisted unless doing so would cause an early error (which is to say, conflict with a lexical declaration). This patch amends the check for conflicting declarations to include those outside of the eval itself. BUG=v8:4468, v8:4479 Review-Url: https://codereview.chromium.org/2112163002 Cr-Commit-Position: refs/heads/master@{#37783}
-
- 13 Jul, 2016 1 commit
-
-
bakkot authored
Reland of Add errors for declarations which conflict with catch parameters. (patchset #1 id:1 of https://codereview.chromium.org/2112223002/ ) Reason for revert: Correcting issue. Original issue's description: > Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ ) > > Reason for revert: > Fuzzer claims `try { \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash. > > Original issue's description: > > Add errors for declarations which conflict with catch parameters. > > > > Catch parameters are largely treated as lexical declarations in the > > block which contains their body for the purposes of early syntax errors, > > with some exceptions outlined in B.3.5. This patch introduces most of > > those errors, except those from `eval('for (var e of ...);')` inside of > > a catch with a simple parameter named 'e'. > > > > Note that annex B.3.5 allows var declarations to conflict with simple > > catch parameters, except when the variable declaration is the init of a > > for-of statement. > > > > BUG=v8:5112,v8:4231 > > > > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406 > > Cr-Commit-Position: refs/heads/master@{#37462} > > TBR=littledan@chromium.org > # Skipping CQ checks because original CL landed less than 1 days ago. > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=v8:5112,v8:4231 > > Committed: https://crrev.com/8834d5ecb559001c87c42322969471da60574a8c > Cr-Commit-Position: refs/heads/master@{#37464} R=littledan@chromium.org BUG=v8:5112,v8:4231 Review-Url: https://codereview.chromium.org/2119933002 Cr-Commit-Position: refs/heads/master@{#37728}
-
- 01 Jul, 2016 2 commits
-
-
bakkot authored
Revert of Add errors for declarations which conflict with catch parameters. (patchset #6 id:100001 of https://codereview.chromium.org/2109733003/ ) Reason for revert: Fuzzer claims `try { \"\" ; } catch(x) { let x1 = [1,,], x = x; }` causes a crash. Original issue's description: > Add errors for declarations which conflict with catch parameters. > > Catch parameters are largely treated as lexical declarations in the > block which contains their body for the purposes of early syntax errors, > with some exceptions outlined in B.3.5. This patch introduces most of > those errors, except those from `eval('for (var e of ...);')` inside of > a catch with a simple parameter named 'e'. > > Note that annex B.3.5 allows var declarations to conflict with simple > catch parameters, except when the variable declaration is the init of a > for-of statement. > > BUG=v8:5112,v8:4231 > > Committed: https://crrev.com/2907c726b2bb5cf20b2bec639ca9e6a521585406 > Cr-Commit-Position: refs/heads/master@{#37462} TBR=littledan@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=v8:5112,v8:4231 Review-Url: https://codereview.chromium.org/2112223002 Cr-Commit-Position: refs/heads/master@{#37464}
-
bakkot authored
Catch parameters are largely treated as lexical declarations in the block which contains their body for the purposes of early syntax errors, with some exceptions outlined in B.3.5. This patch introduces most of those errors, except those from `eval('for (var e of ...);')` inside of a catch with a simple parameter named 'e'. Note that annex B.3.5 allows var declarations to conflict with simple catch parameters, except when the variable declaration is the init of a for-of statement. BUG=v8:5112,v8:4231 Review-Url: https://codereview.chromium.org/2109733003 Cr-Commit-Position: refs/heads/master@{#37462}
-
- 29 Jun, 2016 1 commit
-
-
bakkot authored
In ES2016, function declarations nested in blocks are formally allowed. This was never a part of ECMAScript, but was a common extension. Unfortunately implementations differed in the exact semantics. Annex B.3.3 in the spec tries to standardize the parts which are common to different implementations, but does so with some fairly complicated semantics. This CL addresses three issues related to annex B.3.3: * When the outer function had a complex parameter list, no hoisting whatsoever was being performed. * Hoisting was not blocked by parameters of the same name. * Hoisting was not blocked by nested lexical declarations of the same name. We had tests which checked for the second, but they were incorrectly passing due to the first. This CL adds more complete tests. BUG=v8:5151, v8:5111 Review-Url: https://codereview.chromium.org/2099623003 Cr-Commit-Position: refs/heads/master@{#37405}
-
- 08 Apr, 2016 1 commit
-
-
adamk authored
These were all on by default in M49 without complaint. R=littledan@chromium.org Review URL: https://codereview.chromium.org/1858943002 Cr-Commit-Position: refs/heads/master@{#35342}
-
- 22 Mar, 2016 1 commit
-
-
adamk authored
Now that ES2015 const has shipped, in Chrome 49, legacy const declarations are no more. This lets us remove a bunch of code from many parts of the codebase. In this patch, I remove parser support for generating legacy const variables from const declarations. This also removes the special "illegal declaration" bit from Scope, which has ripples into all compiler backends. Also gone are any tests which relied on legacy const declarations. Note that we do still generate a Variable in mode CONST_LEGACY in one case: function name bindings in sloppy mode. The likely fix there is to add a new Variable::Kind for this case and handle it appropriately for stores in each backend, but I leave that for a later patch to make this one completely subtractive. Review URL: https://codereview.chromium.org/1819123002 Cr-Commit-Position: refs/heads/master@{#35002}
-
- 10 Mar, 2016 1 commit
-
-
adamk authored
These flags have been on by default since version 4.9, which has been in stable Chrome for over a week now, demonstrating that they're here to stay. Also moved the tests out of harmony/ and into es6/. Review URL: https://codereview.chromium.org/1776683003 Cr-Commit-Position: refs/heads/master@{#34692}
-
- 12 Dec, 2015 1 commit
-
-
adamk authored
It shipped in Chrome 47. Review URL: https://codereview.chromium.org/1519073004 Cr-Commit-Position: refs/heads/master@{#32816}
-
- 18 Nov, 2015 1 commit
-
-
adamk authored
This is in preparation for the addition of --harmony-destructuring-assignment. BUG=v8:811 LOG=n Review URL: https://codereview.chromium.org/1450193002 Cr-Commit-Position: refs/heads/master@{#32098}
-
- 30 Sep, 2015 1 commit
-
-
littledan authored
The ES2015 spec is missing an extension of sloppy-mode block-scoped function behavior to the global scope in scripts, as well as to eval. This patch brings that hoisting to those two areas. The behavior is not perfectly spec-compliant since properties created on the global scope should be set as enumerable even if they are non-enumerable previously, but the attributes will not be modified if the property already exists under this patch. BUG=v8:4441 LOG=Y R=adamk TEST=reddit comment functionality seems to be fixed Review URL: https://codereview.chromium.org/1376623002 Cr-Commit-Position: refs/heads/master@{#31037}
-
- 21 Sep, 2015 1 commit
-
-
littledan authored
ES2015 specifies very particular semantics for functions defined in blocks. In strict mode, it is simply a lexical binding scoped to that block. In sloppy mode, in addition to that lexical binding, there is a var-style binding in the outer scope, which is overwritten with the local binding when the function declaration is evaluated, *as long as* introducing ths var binding would not create a var/let conflict in the outer scope. This patch implements the semantics by introducing a DelegateStatement, which is initially filled in with the EmptyStatement and overwritten with the assignment when the scope is closed out and it can be checked that there is no conflict. This patch is tested with a new mjsunit test, and I tried staging it and running test262, finding that the tests that we have disabled due to lack of Annex B support now pass. R=adamk,rossberg LOG=Y BUG=v8:4285 Review URL: https://codereview.chromium.org/1332873003 Cr-Commit-Position: refs/heads/master@{#30842}
-