1. 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
  2. 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
  3. 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
  4. 10 Jul, 2015 1 commit
  5. 08 Jul, 2015 1 commit
  6. 13 Mar, 2015 1 commit
  7. 17 Jun, 2014 1 commit
  8. 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
  9. 25 Oct, 2011 1 commit
  10. 12 Oct, 2011 1 commit
  11. 06 Oct, 2011 1 commit
  12. 30 Aug, 2011 1 commit