1. 26 Nov, 2015 1 commit
  2. 29 Oct, 2015 3 commits
  3. 27 Oct, 2015 1 commit
  4. 21 Oct, 2015 1 commit
    • adamk's avatar
      [es6] Fix scoping for default parameters in arrow functions · 02e4d21f
      adamk authored
      When eagerly parsing arrow functions, expressions in default
      parameter initializers are parsed in the enclosing scope,
      rather than in the function's scope (since that scope does not
      yet exist). This leads to VariableProxies being added to the
      wrong scope, and scope chains for FunctionLiterals being incorrect.
      
      This patch addresses these problems by adding a subclass of
      AstExpressionVisitor that moves VariableProxies to the proper
      scope and fixes up scope chains of FunctionLiterals.
      
      This is a revert of the revert https://crrev.com/e41614a058426fb6102e4ab2dd4f98997f00c0fc
      with a much-improved (though not yet perfect) Scope::ResetOuterScope
      method which properly fixes not only the outer_scope_ pointer but also
      fixes the inner_scope_ list in the relevant outer_scopes.
      
      More work likely still needs to be done to make this work completely,
      but it's very close to correct.
      
      BUG=v8:4395
      LOG=y
      
      Review URL: https://codereview.chromium.org/1414283002
      
      Cr-Commit-Position: refs/heads/master@{#31435}
      02e4d21f
  5. 20 Oct, 2015 2 commits
    • bmeurer's avatar
      Revert of [es6] Fix scoping for default parameters in arrow functions... · e41614a0
      bmeurer authored
      Revert of [es6] Fix scoping for default parameters in arrow functions (patchset #5 id:80001 of https://codereview.chromium.org/1405313002/ )
      
      Reason for revert:
      Breaks nosnap: http://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug%20-%202/builds/2407/steps/Check/logs/regress-4395
      
      Original issue's description:
      > [es6] Fix scoping for default parameters in arrow functions
      >
      > When eagerly parsing arrow functions, expressions in default
      > parameter initializers are parsed in the enclosing scope,
      > rather than in the function's scope (since that scope does not
      > yet exist). This leads to VariableProxies being added to the
      > wrong scope, and scope chains for FunctionLiterals being incorrect.
      >
      > This patch addresses these problems by adding a subclass of
      > AstExpressionVisitor that moves VariableProxies to the proper
      > scope and fixes up scope chains of FunctionLiterals.
      >
      > More work likely still needs to be done to make this work completely,
      > but it's very close to correct.
      >
      > BUG=v8:4395
      > LOG=y
      >
      > Committed: https://crrev.com/cf72aad39e51de9b7074ea039377c1812f4a2c6b
      > Cr-Commit-Position: refs/heads/master@{#31402}
      
      TBR=rossberg@chromium.org,caitpotter88@gmail.com,adamk@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4395
      
      Review URL: https://codereview.chromium.org/1417463004
      
      Cr-Commit-Position: refs/heads/master@{#31404}
      e41614a0
    • adamk's avatar
      [es6] Fix scoping for default parameters in arrow functions · cf72aad3
      adamk authored
      When eagerly parsing arrow functions, expressions in default
      parameter initializers are parsed in the enclosing scope,
      rather than in the function's scope (since that scope does not
      yet exist). This leads to VariableProxies being added to the
      wrong scope, and scope chains for FunctionLiterals being incorrect.
      
      This patch addresses these problems by adding a subclass of
      AstExpressionVisitor that moves VariableProxies to the proper
      scope and fixes up scope chains of FunctionLiterals.
      
      More work likely still needs to be done to make this work completely,
      but it's very close to correct.
      
      BUG=v8:4395
      LOG=y
      
      Review URL: https://codereview.chromium.org/1405313002
      
      Cr-Commit-Position: refs/heads/master@{#31402}
      cf72aad3
  6. 15 Oct, 2015 1 commit
  7. 09 Oct, 2015 1 commit
  8. 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
  9. 30 Sep, 2015 1 commit
  10. 24 Sep, 2015 3 commits
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8fe3ac07
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      CQ_INCLUDE_TRYBOTS=tryserver.v8:v8_linux_layout_dbg,v8_linux_nosnap_dbg
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4413, v8:4430
      LOG=n
      
      Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      Cr-Commit-Position: refs/heads/master@{#30900}
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30902}
      8fe3ac07
    • bmeurer's avatar
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001... · 656ebdce
      bmeurer authored
      Revert of [es6] Introduce spec compliant IsConstructor. (patchset #2 id:20001 of https://codereview.chromium.org/1358423002/ )
      
      Reason for revert:
      Failed on Fuzzer and MIPS bot.
      
      Original issue's description:
      > [es6] Introduce spec compliant IsConstructor.
      >
      > There was already a bit on the Map named "function with prototype",
      > which basically meant that the Map was a map for a JSFunction that could
      > be used as a constructor. Now this CL generalizes that bit to
      > IsConstructor, which says that whatever (Heap)Object you are looking at
      > can be used as a constructor (i.e. the bit is also set for bound
      > functions that can be used as constructors and proxies that have a
      > [[Construct]] internal method).
      >
      > This way we have a single chokepoint for IsConstructor checking, which
      > allows us to get rid of the various ways in which we tried to guess
      > whether something could be used as a constructor or not.
      >
      > Drive-by-fix: Renamed IsConstructor on FunctionKind to
      > IsClassConstructor to resolve the weird name clash, and the
      > IsClassConstructor name also matches the spec.
      >
      > R=jarin@chromium.org, rossberg@chromium.org
      > BUG=v8:4430
      > LOG=n
      >
      > Committed: https://crrev.com/8de4d9351df4cf66c8a128d561a6e331d196be54
      > Cr-Commit-Position: refs/heads/master@{#30900}
      
      TBR=jarin@chromium.org,rossberg@chromium.org
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:4430
      
      Review URL: https://codereview.chromium.org/1360403002
      
      Cr-Commit-Position: refs/heads/master@{#30901}
      656ebdce
    • bmeurer's avatar
      [es6] Introduce spec compliant IsConstructor. · 8de4d935
      bmeurer authored
      There was already a bit on the Map named "function with prototype",
      which basically meant that the Map was a map for a JSFunction that could
      be used as a constructor. Now this CL generalizes that bit to
      IsConstructor, which says that whatever (Heap)Object you are looking at
      can be used as a constructor (i.e. the bit is also set for bound
      functions that can be used as constructors and proxies that have a
      [[Construct]] internal method).
      
      This way we have a single chokepoint for IsConstructor checking, which
      allows us to get rid of the various ways in which we tried to guess
      whether something could be used as a constructor or not.
      
      Drive-by-fix: Renamed IsConstructor on FunctionKind to
      IsClassConstructor to resolve the weird name clash, and the
      IsClassConstructor name also matches the spec.
      
      R=jarin@chromium.org, rossberg@chromium.org
      BUG=v8:4430
      LOG=n
      
      Review URL: https://codereview.chromium.org/1358423002
      
      Cr-Commit-Position: refs/heads/master@{#30900}
      8de4d935
  11. 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
  12. 08 Sep, 2015 1 commit
    • mstarzinger's avatar
      Use baseline code to compute message locations. · 819b40aa
      mstarzinger authored
      This switches Isolate::ComputeLocation to use baseline code when
      computing message locations. This unifies locations between optimized
      and non-optimized code by always going through the FrameSummary for
      location computation.
      
      R=bmeurer@chromium.org
      TEST=message/regress/regress-4266
      BUG=v8:4266
      LOG=n
      
      Review URL: https://codereview.chromium.org/1331603002
      
      Cr-Commit-Position: refs/heads/master@{#30635}
      819b40aa
  13. 28 Aug, 2015 1 commit
    • littledan's avatar
      Ensure hole checks take place in switch statement scopes · d6fb6de7
      littledan authored
      Switch statements introduce their own scope for cases, but this scope
      is not necessarily executed in order, as the following function shows:
      
        switch (x) {
          case 1:
            let y = 1;
          case 2:
            y = 2;
          case 3:
            print(y);
        }
      
      If x = 2 or x = 3, the code should throw a ReferenceError. However,
      FullCodeGen's hole check elimination used the simple algorithm of
      assuming that if the initializer was in the same scope, then it was
      reached before the use, and therefore the hole check could be
      eliminated.
      
      This patch adds an extra bit to scopes, to track if they may
      nonlinearly. The parser marks the scope that switch introduces as
      nonlinear. FullCodeGen does not eliminate the hole check from
      a scope which is nonlinear. This patch refactors FullCodeGen to
      put the hole check elimination in one place, rather than in each
      backend.
      
      BUG=v8:3926
      LOG=Y
      R=adamk
      
      Review URL: https://codereview.chromium.org/1312613003
      
      Cr-Commit-Position: refs/heads/master@{#30453}
      d6fb6de7
  14. 26 Aug, 2015 1 commit
  15. 25 Aug, 2015 1 commit
  16. 24 Aug, 2015 1 commit
    • littledan's avatar
      Add a separate scope for switch · 45e2628d
      littledan authored
      The ES2015 specification for switch statements 13.12.11 specifies that
      they get their own lexical scope. This patch introduces such a scope
      through a complex desugaring in terms of blocks, done so that Crankshaft
      does not have to be updated to support multiple constructs providing
      scopes.
      
      Recommitting this patch after a bug fix in Crankshaft to allow a
      desugaring with certain elements missing a source location:
      https://codereview.chromium.org/1313443002
      
      BUG=v8:4377
      LOG=Y
      R=adamk
      
      Review URL: https://codereview.chromium.org/1309163003
      
      Cr-Commit-Position: refs/heads/master@{#30340}
      45e2628d
  17. 22 Aug, 2015 1 commit
  18. 21 Aug, 2015 2 commits
    • littledan's avatar
      Add a separate scope for switch · 9edbc1f2
      littledan authored
      The ES2015 specification for switch statements 13.12.11 specifies that
      they get their own lexical scope. This patch introduces such a scope
      through a complex desugaring in terms of blocks, done so that Crankshaft
      does not have to be updated to support multiple constructs providing
      scopes.
      
      BUG=v8:4377
      LOG=Y
      R=adamk
      
      Review URL: https://codereview.chromium.org/1293283002
      
      Cr-Commit-Position: refs/heads/master@{#30314}
      9edbc1f2
    • 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
  19. 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
  20. 07 Aug, 2015 1 commit
  21. 24 Jul, 2015 2 commits
  22. 23 Jul, 2015 2 commits
  23. 20 Jul, 2015 1 commit
  24. 15 Jul, 2015 1 commit
  25. 06 Jul, 2015 1 commit
  26. 01 Jul, 2015 1 commit
  27. 30 Jun, 2015 1 commit
  28. 29 Jun, 2015 1 commit
  29. 12 Jun, 2015 4 commits