Fix priority of exceptions being thrown from for-of loops

Fix priority of exceptions being thrown from for-of loops

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

Committed: https://crrev.com/5f67e34aed279d3239f66f8fb0a26e650ec7bb79
Cr-Commit-Position: refs/heads/master@{#34261}

[Dan Ehrenberg, 2016-02-24 01:25:56]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-24 01:26:07]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1728973002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1728973002/20001

[commit-bot: I haz the power, 2016-02-24 01:28:48]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 01:28:49]

Dry run: Try jobs failed on following builders:
  v8_presubmit on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/11405)

[Dan Ehrenberg, 2016-02-24 01:35:11]

The CQ bit was checked by littledan@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-24 01:35:19]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1728973002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1728973002/40001

[Dan Ehrenberg, 2016-02-24 01:51:47]

littledan@chromium.org changed reviewers:
+ adamk@chromium.org

[Dan Ehrenberg, 2016-02-24 02:08:30]

littledan@chromium.org changed reviewers:
- adamk@chromium.org

[commit-bot: I haz the power, 2016-02-24 02:53:02]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 02:53:03]

Dry run: This issue passed the CQ dry run.

[rossberg, 2016-02-24 14:08:58]

lgtm

[Dan Ehrenberg, 2016-02-24 18:01:05]

The CQ bit was checked by littledan@chromium.org

[Dan Ehrenberg, 2016-02-24 18:01:05]

The patchset sent to the CQ was uploaded after l-g-t-m from
rossberg@chromium.org
Link to the patchset: https://codereview.chromium.org/1728973002/#ps60001
(title: "Rebase, with test262 expectations updated")

[commit-bot: I haz the power, 2016-02-24 18:01:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1728973002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1728973002/60001

[commit-bot: I haz the power, 2016-02-24 18:21:38]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-02-24 18:21:53]

Description was changed from

==========
Fix priority of exceptions being thrown from for-of loops

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
==========

to

==========
Fix priority of exceptions being thrown from for-of loops

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

Committed: https://crrev.com/5f67e34aed279d3239f66f8fb0a26e650ec7bb79
Cr-Commit-Position: refs/heads/master@{#34261}
==========

[commit-bot: I haz the power, 2016-02-24 18:21:54]

Patchset 4 (id:??) landed as
https://crrev.com/5f67e34aed279d3239f66f8fb0a26e650ec7bb79
Cr-Commit-Position: refs/heads/master@{#34261}