1. 10 Aug, 2016 1 commit
    • adamk's avatar
      Function name variable does not need a VariableDeclaration · 73b0f157
      adamk authored
      This changes Scope::function_ (for holding the name binding
      for named function expression) from a VariableDeclaration
      to a Variable. No work is done when visiting this declaration,
      since it's kCreatedInitialized, so we can treat it like
      other function-specific variables.
      
      This simplifies a wide variety of code, and centralizes
      the logic for constructing the variable inside scopes.cc.
      This may one day make it easier to eliminate the CONST_LEGACY
      VariableMode.
      
      R=neis@chromium.org, verwaest@chromium.org
      BUG=v8:5209
      
      Review-Url: https://codereview.chromium.org/2232633002
      Cr-Commit-Position: refs/heads/master@{#38558}
      73b0f157
  2. 05 Aug, 2016 3 commits
  3. 01 Aug, 2016 1 commit
  4. 28 Jun, 2016 1 commit
  5. 27 Apr, 2016 1 commit
  6. 18 Feb, 2016 1 commit
  7. 03 Dec, 2015 3 commits
  8. 26 Nov, 2015 1 commit
  9. 07 Oct, 2015 1 commit
    • adamk's avatar
      Use Scope::function_kind_ to distinguish arrow function scopes · 24565b85
      adamk authored
      Previously, arrow function scopes had a separate ScopeType. However,
      Scope::DeserializeScopeChain() erroneously deserialized ARROW_SCOPE
      ScopeInfos as FUNCTION_SCOPE. This could lead to bugs such as the
      attached one, where "super" was disallowed where it should have
      been allowed.
      
      This patch utilizes the Scope's FunctionKind to distinguish arrow
      functions from others. Besides fixing the above bug, this also
      simplifies code in various places that had to deal with two different
      ScopeTypes both of which meant "function".
      
      BUG=v8:4466
      LOG=n
      
      Review URL: https://codereview.chromium.org/1386253002
      
      Cr-Commit-Position: refs/heads/master@{#31154}
      24565b85
  10. 28 Sep, 2015 1 commit
  11. 10 Sep, 2015 1 commit
  12. 21 Aug, 2015 1 commit
    • rossberg's avatar
      [es6] Parameter scopes for sloppy eval · 365fd7bc
      rossberg authored
      This CL is a nightmare! For the utterly irrelevant edge case of a sloppy function with non-simple parameters and a call to direct eval, like here,
      
        let x = 1;
        function f(g = () => x) {
          var y
          eval("var x = 2")
          return g() + x  // f() = 3
        }
      
      we have to do all of the following, on top of the declaration block ("varblock") contexts we already introduce around the body:
      
      - Introduce the ability for varblock contexts to have both a ScopeInfo and an extension object (e.g., the body varblock in the example will contain both a static var y and a dynamic var x). No other scope needs that. Since there are no context slots left, a special new struct is introduced that pairs up scope info and extension object.
      
      - When declaring lookup slots in the runtime, this new struct is allocated in the case where an extension object has to be added to a block scope (at which point the block's extension slot still contains a plain ScopeInfo).
      
      - While at it, introduce some abstraction to access context extension slots in a more controlled manner, in order to keep special-casing to a minimum.
      
      - Make sure that even empty varblock contexts do not get optimised away when they contain a sloppy eval, so that they can host the potential extension object.
      
      - Extend dynamic search for declaration contexts (used by sloppy direct eval) to recognize varblock contexts.
      
      - In the parser, if a function has a sloppy direct eval, introduce an additional varblock scope around each non-simple (desugared) parameter, as required by the spec to contain possible dynamic var bindings.
      
      - In the pattern rewriter, add the ability to hoist the named variables the pattern declares to an outer scope. That is required because the actual destructuring has to be evaluated inside the protecting varblock scope, but the bindings that the desugaring introduces are in the outer scope.
      
      - ScopeInfos need to save the information whether a block is a varblock, to make sloppy eval calls work correctly that deserialise them as part of the scope chain.
      
      - Add the ability to materialize block scopes with extension objects in the debugger. Likewise, enable setting extension variables in block scopes via the debugger interface.
      
      - While at it, refactor and unify some respective code in the debugger.
      
      Sorry, this CL is large. I could try to split it up, but everything is rather entangled.
      
      @mstarzinger: Please review the changes to contexts.
      @yangguo: Please have a look at the debugger stuff.
      
      R=littledan@chromium.org, mstarzinger@chromium.org, yangguo@chromium.org
      BUG=v8:811,v8:2160
      LOG=N
      
      Review URL: https://codereview.chromium.org/1292753007
      
      Cr-Commit-Position: refs/heads/master@{#30295}
      365fd7bc
  13. 20 Aug, 2015 1 commit
  14. 13 Aug, 2015 1 commit
  15. 07 Aug, 2015 2 commits
  16. 04 Aug, 2015 1 commit
  17. 28 Jul, 2015 2 commits
  18. 23 Jul, 2015 1 commit
  19. 06 Jul, 2015 1 commit
  20. 01 Jul, 2015 1 commit
  21. 12 Jun, 2015 6 commits
  22. 11 Jun, 2015 2 commits
  23. 01 Jun, 2015 1 commit
  24. 19 May, 2015 2 commits
  25. 18 May, 2015 1 commit
  26. 13 May, 2015 1 commit
  27. 11 May, 2015 1 commit