1. 02 Sep, 2015 1 commit
  2. 26 Aug, 2015 1 commit
  3. 25 Aug, 2015 2 commits
  4. 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
  5. 22 Aug, 2015 1 commit
  6. 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
  7. 19 Aug, 2015 1 commit
  8. 17 Aug, 2015 1 commit
  9. 05 Aug, 2015 1 commit
    • rossberg's avatar
      [es6] Implement proper TDZ for parameters · 4273f66e
      rossberg authored
      Previously, examples like (({a = x}, x) => {})({}, 0) did not throw a ReferenceError like they should. This CL
      
      - Splits up DeclareFormalParameters such that the formals can be recorded first and declared later.
      
      - Declaration then takes the complete parameter list into account. If it is not simple, temporaries are introduced for all parameters.
      
      - BuildParameterInitializationBlock desugars all parameters from non-simple lists into let-bindings.
      
      - Refactored Pre/ParserFormalParameters, so that the arity information is no longer duplicated in Parser.
      
      - Rest is currently handled specially, until rest-via-destructuring has landed.
      
      R=adamk@chromium.org, littledan@chromium.org
      BUG=v8:811
      LOG=N
      
      Review URL: https://codereview.chromium.org/1259283002
      
      Cr-Commit-Position: refs/heads/master@{#30025}
      4273f66e
  10. 04 Aug, 2015 2 commits
    • rossberg's avatar
      [es6] Refactor FormalParameter · 56bd11a1
      rossberg authored
      Store arity in FormalParameters; store name (instead of var) and is_rest flag in individual parameters. Ensure that the arity is always maintained consistently.
      
      This is preparation for more parameter destructuring adjustments. In particular, a follow-up CL will separate parameter recording from declaring the variables.
      
      R=adamk@chromium.org, littledan@chromium.org
      BUG=v8:811
      LOG=N
      
      Review URL: https://codereview.chromium.org/1259013003
      
      Cr-Commit-Position: refs/heads/master@{#30002}
      56bd11a1
    • rossberg's avatar
      Correct handling of temporaries as parameters. · 222b70d1
      rossberg authored
      They need to be properly recorded in the scope's temps set, otherwise allocation doesn't know about them and can break. (Not observable right now, but necessary for follow-up changes to parameter destructuring.)
      
      Also, print temporary variables in a useful manner.
      
      R=adamk@chromium.org
      BUG=
      
      Review URL: https://codereview.chromium.org/1263563002
      
      Cr-Commit-Position: refs/heads/master@{#29998}
      222b70d1
  11. 03 Aug, 2015 1 commit
  12. 23 Jul, 2015 2 commits
  13. 16 Jul, 2015 1 commit
  14. 15 Jul, 2015 1 commit
  15. 09 Jul, 2015 1 commit
    • adamk's avatar
      Fix lazy compilation of eval() under nosnap/--use-strict · 33a37398
      adamk authored
      When running without a snapshot, the GlobalEval function gets lazy compiled.
      By the time we compile it, its name is "eval", which causes the parser to
      choke (functions named "eval" aren't allowed in strict mode!).
      
      Instead, we now always skip checking the function name when lazy-parsing,
      as the name has already been checked appropriately by the preparser.
      
      Also cleaned up other cases that don't require name checking by introducing
      FunctionNameValidity enum and passing appropriate values throughout the
      parser and preparser.
      
      This lets us pass an additional 18 test262 tests.
      
      BUG=v8:4198
      LOG=n
      
      Review URL: https://codereview.chromium.org/1227093005
      
      Cr-Commit-Position: refs/heads/master@{#29559}
      33a37398
  16. 26 Jun, 2015 1 commit
  17. 24 Jun, 2015 1 commit
  18. 22 Jun, 2015 3 commits
  19. 15 Jun, 2015 1 commit
  20. 10 Jun, 2015 1 commit
  21. 09 Jun, 2015 4 commits
  22. 04 Jun, 2015 1 commit
  23. 02 Jun, 2015 1 commit
    • arv's avatar
      [es6] Super call in arrows and eval · 4b8051a0
      arv authored
      This splits the SuperReference AST node into SuperPropertyReference and
      SuperCallReference. The super call reference node consists of three
      unresolved vars to this, new.target and this_function. These gets
      declared when the right function is entered and if it is in use. The
      variables gets assigned in FullCodeGenerator::Generate.
      
      This is a revert of the revert 88b1c917
      
      BUG=v8:3768
      LOG=N
      R=wingo@igalia.com, adamk@chromium.org
      
      Review URL: https://codereview.chromium.org/1168513004
      
      Cr-Commit-Position: refs/heads/master@{#28769}
      4b8051a0
  24. 01 Jun, 2015 4 commits
  25. 26 May, 2015 1 commit
    • arv's avatar
      [es6] Support super.property in eval and arrow functions · 44e98103
      arv authored
      When we enter a method that needs access to the [[HomeObject]]
      we allocate a local variable `.home_object` and assign it the
      value from the [[HomeObject]] private symbol. Something along
      the lines of:
      
        method() {
          var .home_object = %ThisFunction()[home_object_symbol];
          ...
        }
      
      BUG=v8:3867, v8:4031
      LOG=N
      
      Review URL: https://codereview.chromium.org/1135243004
      
      Cr-Commit-Position: refs/heads/master@{#28644}
      44e98103
  26. 21 May, 2015 1 commit
    • dslomov's avatar
      [destructuring] Grand for statement parsing unification. · 7ffdb519
      dslomov authored
      Also support patterns in ``for (var p in/of ...)``
      
      This CL extends the rewriting we used to do for ``for (let p in/of...)`` to
      ``for (var p in/of ...)``. For all for..in/of loop declaring variable,
      we rewrite
         for (var/let/const pattern in/of e) b
      into
         for (x' in/of e) { var/let/const pattern = e; b }
      
      This adds a small complication for debugger: for a statement
         for (var v in/of e) ...
      we used to have
         var v;
         for (v in/of e) ...
      and there was a separate breakpoint on ``var v`` line.
      This breakpoint is actually useless since it is immediately followed by
      a breakpoint on evaluation of ``e``, so this CL removes that breakpoint
      location.
      
      Similiraly, for let, it used to be that
        for (let v in/of e) ...
      became
        for (x' in/of e) { let v; v  = x'; ... }
      ``let v``generetaed a useless breakpoint (with the location at the
      loop's head. This CL removes that breakpoint as well.
      
      R=arv@chromium.org,rossberg@chromium.org
      BUG=v8:811
      LOG=N
      
      Review URL: https://codereview.chromium.org/1149043005
      
      Cr-Commit-Position: refs/heads/master@{#28565}
      7ffdb519
  27. 20 May, 2015 1 commit
  28. 19 May, 2015 1 commit