1. 07 Sep, 2016 1 commit
  2. 14 Jul, 2016 1 commit
  3. 13 Jul, 2016 1 commit
    • bakkot's avatar
      Reland of Add errors for declarations which conflict with catch parameters.... · 819fe046
      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}
      819fe046
  4. 01 Jul, 2016 2 commits
    • bakkot's avatar
      Revert of Add errors for declarations which conflict with catch parameters.... · 8834d5ec
      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}
      8834d5ec
    • bakkot's avatar
      Add errors for declarations which conflict with catch parameters. · 2907c726
      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}
      2907c726
  5. 29 Jun, 2016 1 commit
    • bakkot's avatar
      Sloppy-mode function declarations in blocks are now hoisted appropriately. · 9bbba144
      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}
      9bbba144
  6. 08 Apr, 2016 1 commit
  7. 22 Mar, 2016 1 commit
    • adamk's avatar
      Remove support for legacy const, part 1 · ed18aa65
      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}
      ed18aa65
  8. 10 Mar, 2016 1 commit
  9. 12 Dec, 2015 1 commit
  10. 18 Nov, 2015 1 commit
  11. 30 Sep, 2015 1 commit
    • littledan's avatar
      Extend Annex B 3.3 sloppy-mode block-scoped hoisting to scripts, eval · 76da4933
      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}
      76da4933
  12. 21 Sep, 2015 1 commit
    • littledan's avatar
      Implement sloppy-mode block-defined functions (Annex B 3.3) · e5ff10d7
      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}
      e5ff10d7