1. 06 Jun, 2019 1 commit
  2. 07 Jul, 2016 1 commit
  3. 24 Jun, 2016 1 commit
  4. 02 Jun, 2016 1 commit
  5. 28 Apr, 2016 1 commit
  6. 10 Mar, 2016 2 commits
  7. 24 Feb, 2016 2 commits
    • littledan's avatar
      Ensure IteratorClose is called for errors in non-declaring assignments · 1aee7555
      littledan authored
      There was a bug in for-of loops without newly declared variables: If,
      in performing the assignment, an exception were thrown, then
      IteratorClose would not be called. The problem was that the assignment
      is done as part of assign_each, which happens before the loop is put
      back in the state which is recognized to be breaking/throwing/returning
      early.
      
      This patch modifies the for-of desugaring by setting the loop state
      before, rather than after, evaluating the assign_each portion, which is
      responsible for evaluating the assignment in for-of loops which do not
      have a declaration.
      
      This patch, together with https://codereview.chromium.org/1728973002 ,
      allow all test262 iterator return-related tests to pass.
      
      R=rossberg
      BUG=v8:4776
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1731773003
      
      Cr-Commit-Position: refs/heads/master@{#34262}
      1aee7555
    • littledan's avatar
      Fix priority of exceptions being thrown from for-of loops · 5f67e34a
      littledan authored
      In the for-of desugaring, IteratorClose is a subtle thing to get right.
      When return exists, the logic for which exception to throw is as follows:
      1. Get the 'return' property and property any exception that might come from
        the property read
      2. Call return, not yet propagating an exception if it's thrown.
      3. If we are closing the iterator due to an exception, propagate that error.
      4. If return threw, propagate that error.
      5. Check if return's return value was not an object, and throw if so
      
      Previously, we were effectively doing step 5 even if an exception "had already
      been thrown" by step 3. Because this took place in a finally block, the exception
      "won the race" and was the one propagated to the user. The fix is a simple change
      to the desugaring to do step 5 only if step 3 didn't happen.
      
      R=rossberg
      BUG=v8:4775
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1728973002
      
      Cr-Commit-Position: refs/heads/master@{#34261}
      5f67e34a
  8. 18 Feb, 2016 1 commit
    • rossberg's avatar
      [es6] Implement for-of iterator finalization · cb1bf4af
      rossberg authored
      Implements iterator finalisation by desugaring for-of loops with an additional try-finally wrapper. See comment in parser.cc for details.
      
      Also improved some AST printing facilities while there.
      
      @Ross, I had to disable the bytecode generation test for for-of, because it got completely out of hand after this change (the new bytecode has 150+ lines). See the TODO that I assigned to you.
      
      Patch set 1 is WIP patch by Georg (http://crrev.com/1695583003), patch set 2 relative changes.
      
      @Georg, FYI, I changed the following:
      
      - Moved try-finally out of the loop body, for performance, and in order to be able to handle `continue` correctly.
      - Fixed scope management in ParseForStatement, which was the cause for the variable allocation failure.
      - Fixed pre-existing zone initialisation bug in rewriter, which caused the crashes.
      - Enabled all tests, adjusted a few others, added a couple more.
      
      BUG=v8:2214
      LOG=Y
      
      Review URL: https://codereview.chromium.org/1695393003
      
      Cr-Commit-Position: refs/heads/master@{#34111}
      cb1bf4af