- 06 Jun, 2019 1 commit
-
-
Swapnil Gaikwad authored
As per the new specs, when the exception is thrown by iterator's return method while doing iterator close because it is not callable, the exception is suppressed in the same way as if the return method is called and threw an exception. https://github.com/tc39/ecma262/issues/1398 Bug: v8:9056 Change-Id: I21abd5fdd01d3a957c3c16d9d3aaab9091e43142 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648256Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#62035}
-
- 07 Jul, 2016 1 commit
-
-
neis authored
When reading the value property of an iterator result fails, we must not close the iterator. This was not discovered earlier because the tests had a subtle bug. This CL fixes both the desugaring and the tests. BUG= Review-Url: https://codereview.chromium.org/2119353002 Cr-Commit-Position: refs/heads/master@{#37571}
-
- 24 Jun, 2016 1 commit
-
-
adamk authored
Flags removed (all begin with "harmony-"): function-name instanceof iterator-close unicode-regexps regexp-exec regexp-subclass species BUG=v8:3566, v8:3648, v8:3699, v8:4093, v8:4447, v8:4602 Review-Url: https://codereview.chromium.org/2096933002 Cr-Commit-Position: refs/heads/master@{#37235}
-
- 02 Jun, 2016 1 commit
-
-
neis authored
In one corner case, we incorrectly returned a value without first wrapping it in an iterator result object. R=littledan@chromium.org BUG=v8:5057 Review-Url: https://codereview.chromium.org/2034653002 Cr-Commit-Position: refs/heads/master@{#36676}
-
- 28 Apr, 2016 1 commit
-
-
neis authored
This fixes a bug where the iterable's .return method gets called when it shouldn't. R=littledan@chromium.org BUG=v8:4952 LOG=n Review-Url: https://codereview.chromium.org/1927073002 Cr-Commit-Position: refs/heads/master@{#35850}
-
- 10 Mar, 2016 2 commits
-
-
neis authored
The comment was correct but the code didn't match :( Must not close when .value throws. R=adamk@chromium.org BUG=v8:3566 LOG=n Review URL: https://codereview.chromium.org/1778333002 Cr-Commit-Position: refs/heads/master@{#34691}
-
neis authored
We must close the iterator whenever the destructuring didn't exhaust it, unless an iterator operation (eg. next) threw. We do this by wrapping the iterator use in a try-catch-finally similar to the desugaring of for-of. This is behind --harmony-iterator-close. R=adamk@chromium.org BUG=v8:3566 LOG=Y Review URL: https://codereview.chromium.org/1772793002 Cr-Commit-Position: refs/heads/master@{#34654}
-
- 24 Feb, 2016 2 commits
-
-
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}
-
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}
-
- 18 Feb, 2016 1 commit
-
-
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}
-