1. 16 Sep, 2019 1 commit
  2. 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
  3. 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
  4. 08 Apr, 2016 1 commit
  5. 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
  6. 12 Aug, 2015 2 commits
    • littledan's avatar
      Add class to existing lexical scoping tests · e261540b
      littledan authored
      This patch strengthens testing of classes by verifying that the binding
      that they export externally follows block scoping, as opposed to var-style
      scoping. The tests are based on existing tests for let and const.
      
      R=adamk
      LOG=N
      BUG=v8:3305
      
      Review URL: https://codereview.chromium.org/1286923002
      
      Cr-Commit-Position: refs/heads/master@{#30140}
      e261540b
    • littledan's avatar
      Split function block scoping into a separate flag · 1ebf0d7c
      littledan authored
      In an initial attempt to implement sloppy mode lexical bindings,
      functions were made lexically scoped in sloppy mode. However, the
      ES2015 spec says that they need an additional hoisted var binding,
      and further, it's not clear when we'll implement that behavior
      or whether it's web-compatible.
      
      This patch splits off function block scoping into a new, separate
      flag called --harmony_sloppy_function. This change will enable the
      possibility of testing and shipping this feature separately from
      other block scoping-related features which don't have the same risks.
      
      BUG=v8:4285
      R=adamk
      LOG=N
      
      Review URL: https://codereview.chromium.org/1282093002
      
      Cr-Commit-Position: refs/heads/master@{#30122}
      1ebf0d7c
  7. 11 Aug, 2015 1 commit
    • littledan's avatar
      Use a new lexical context for sloppy-mode eval · d03191be
      littledan authored
      In ES6, direct eval() in sloppy mode uses the enclosing function-level
      ("var") scope for var-style bindings and a new lexical scope for lexical
      bindings like let and class. This patch implements that feature by making
      lexical bindings that are directly within an EVAL_SCOPE be on the local
      scope rather than the enclosing one.
      
      BUG=v8:4288
      LOG=Y
      R=adamk
      
      Review URL: https://codereview.chromium.org/1274193004
      
      Cr-Commit-Position: refs/heads/master@{#30120}
      d03191be
  8. 25 Jul, 2015 1 commit
    • littledan's avatar
      Split off a separate --harmony_sloppy_let flag · 2d2b72f6
      littledan authored
      --harmony_sloppy includes behavior to turn on sloppy mode lexical
      bindings. Before this patch, it also included a way to parse let
      which is likely web-incompatible (let is disallowed as an
      identifier). This patch splits off the let parsing from the more
      general block scoping code, so that block scoping can be developed
      independently.
      
      R=adamk
      LOG=N
      BUG=v8:3305
      
      Review URL: https://codereview.chromium.org/1255013002
      
      Cr-Commit-Position: refs/heads/master@{#29855}
      2d2b72f6
  9. 10 Jul, 2015 1 commit
  10. 13 Mar, 2015 1 commit
  11. 25 Nov, 2014 1 commit
  12. 09 Jul, 2014 1 commit
  13. 17 Jun, 2014 1 commit
  14. 28 Aug, 2012 1 commit
    • rossberg@chromium.org's avatar
      Allocate block-scoped global bindings to global context. · ccc827a6
      rossberg@chromium.org authored
      - The global object has a reference to the current global scope chain.
        Running a script adds to the chain if it contains global lexical declarations.
      - Scripts are executed relative to a global, not a native context.
      - Harmony let and const bindings are allocated to the innermost global context;
        var and function still live on the global object.
        (Lexical bindings are not reflected on the global object at all,
        but that will probably change later using accessors, as for modules.)
      - Compilation of scripts now needs a (global) context (previously only eval did).
      - The global scope chain represents one logical scope, so collision tests take
        the chain into account.
      
      R=svenpanne@chromium.org
      BUG=
      
      Review URL: https://chromiumcodereview.appspot.com/10872084
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@12398 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      ccc827a6
  15. 14 Feb, 2012 1 commit
  16. 24 Nov, 2011 1 commit
    • keuchel@chromium.org's avatar
      Introduce extended mode. · 1e9a7267
      keuchel@chromium.org authored
      This CL introduces a third mode next to the non-strict
      (henceforth called 'classic mode') and 'strict mode'
      which is called 'extended mode' as in the current
      ES.next specification drafts. The extended mode is based on
      the 'strict mode' and adds new functionality to it. This
      means that most of the semantics of these two modes
      coincide.
      
      The 'extended mode' is entered instead of the 'strict mode'
      during parsing when using the 'strict mode' directive
      "use strict" and when the the harmony-scoping flag is
      active. This should be changed once it is fully specified how the 'extended mode' is entered.
      
      This change introduces a new 3 valued enum LanguageMode
      (see globals.h) corresponding to the modes which is mostly
      used by the frontend code. This includes the following
      components:
      * (Pre)Parser
      * Compiler
      * SharedFunctionInfo, Scope and ScopeInfo
      * runtime functions: StoreContextSlot,
        ResolvePossiblyDirectEval, InitializeVarGlobal,
        DeclareGlobals
      
      The old enum StrictModeFlag is still used in the backend
      when the distinction between the 'strict mode' and the 'extended mode' does not matter. This includes:
      * SetProperty runtime function, Delete builtin
      * StoreIC and KeyedStoreIC
      * StubCache
      
      Review URL: http://codereview.chromium.org/8417035
      
      git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10062 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      1e9a7267
  17. 25 Oct, 2011 1 commit
  18. 12 Oct, 2011 1 commit
  19. 01 Sep, 2011 1 commit