[debug] use catch prediction flag for promise rejections.

[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.

BUG=v8:5167
Committed: https://crrev.com/6d0a4202982529630e7f7e636b25f267b7fe8857
Cr-Commit-Position: refs/heads/master@{#37966}

[Yang, 2016-07-20 08:58:25]

Description was changed from

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) {} indicates a TryCatchStatement with the "promise"
prediction.

BUG=v8:5167
==========

to

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

BUG=v8:5167
==========

[Yang, 2016-07-20 09:00:04]

yangguo@chromium.org changed reviewers:
+ littledan@chromium.org, mstarzinger@chromium.org

[Yang, 2016-07-20 09:00:04]

Please take a look.

[Yang, 2016-07-20 09:01:38]

Description was changed from

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

BUG=v8:5167
==========

to

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.


BUG=v8:5167
==========

[Michael Starzinger, 2016-07-20 09:20:18]

LGTM. Thanks! I looked at everything aside from the parser. Also note that I
don't have an opinion about the new catch syntax. I'll leave that to parser
owners.

https://codereview.chromium.org/2161263003/diff/1/src/ast/ast-numbering.cc
File src/ast/ast-numbering.cc (right):

https://codereview.chromium.org/2161263003/diff/1/src/ast/ast-numbering.cc#ne...
src/ast/ast-numbering.cc:297: // we adopt the prediction of the outer try-block.
nit: s/outer/surrounding/

[Yang, 2016-07-21 05:43:55]

On 2016/07/20 09:20:18, Michael Starzinger wrote:
> LGTM. Thanks! I looked at everything aside from the parser. Also note that I
> don't have an opinion about the new catch syntax. I'll leave that to parser
> owners.
> 
> https://codereview.chromium.org/2161263003/diff/1/src/ast/ast-numbering.cc
> File src/ast/ast-numbering.cc (right):
> 
>
https://codereview.chromium.org/2161263003/diff/1/src/ast/ast-numbering.cc#ne...
> src/ast/ast-numbering.cc:297: // we adopt the prediction of the outer
try-block.
> nit: s/outer/surrounding/

ping

[Dan Ehrenberg, 2016-07-21 21:07:34]

lgtm

Not necessarily the syntax I would have gone with (it's not very
self-explanatory, and we don't document it anywhere) but this is only for
natives and we are thinking of rewriting the code anyway.

https://codereview.chromium.org/2161263003/diff/1/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/2161263003/diff/1/src/isolate.cc#newcode1281
src/isolate.cc:1281: if (prediction != HandlerTable::UNCAUGHT) return
CAUGHT_BY_JAVASCRIPT;
This is big--it deserves a comment mentioning the implications for Promises.

https://codereview.chromium.org/2161263003/diff/1/src/isolate.cc#newcode1698
src/isolate.cc:1698: if (prediction == HandlerTable::PROMISE) {
Beautiful

https://codereview.chromium.org/2161263003/diff/1/src/parsing/parser.cc
File src/parsing/parser.cc (right):

https://codereview.chromium.org/2161263003/diff/1/src/parsing/parser.cc#newco...
src/parsing/parser.cc:2992: DCHECK_EQ(Token::CATCH, tok);
Nit: I wonder if we should use CHECK here; if it weren't native-only, we'd want
to make a good syntax error. We do have good syntax errors for other natives
cases, like runtime functions called with the wrong number of arguments.

https://codereview.chromium.org/2161263003/diff/1/test/mjsunit/es6/debug-prom...
File test/mjsunit/es6/debug-promises/throw-with-throw-in-reject.js (left):

https://codereview.chromium.org/2161263003/diff/1/test/mjsunit/es6/debug-prom...
test/mjsunit/es6/debug-promises/throw-with-throw-in-reject.js:53:
assertEquals("reject", event_data.exception().message);
Nice fix; this really isn't a rejection.

[Dan Ehrenberg, 2016-07-21 21:08:51]

https://codereview.chromium.org/2161263003/diff/1/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/2161263003/diff/1/src/isolate.cc#newcode1281
src/isolate.cc:1281: if (prediction != HandlerTable::UNCAUGHT) return
CAUGHT_BY_JAVASCRIPT;
On 2016/07/21 at 21:07:33, Dan Ehrenberg wrote:
> This is big--it deserves a comment mentioning the implications for Promises.

Sorry, please ignore this comment; I wrote it while in the process of
understanding the code and forgot to delete it.

[Yang, 2016-07-22 05:25:51]

The CQ bit was checked by yangguo@chromium.org

[commit-bot: I haz the power, 2016-07-22 05:25:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-22 06:04:17]

Description was changed from

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.


BUG=v8:5167
==========

to

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.


BUG=v8:5167
==========

[commit-bot: I haz the power, 2016-07-22 06:04:18]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-07-22 06:05:03]

Description was changed from

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.


BUG=v8:5167
==========

to

==========
[debug] use catch prediction flag for promise rejections.

This is in preparation to implementing exception prediction for async
functions.  Each handler table entry can now predict "caught", "uncaught", or
"promise". The latter indicates that the exception will lead to a promise
rejection.

To mark the relevant try-catch blocks, we add a new native syntax.
try { } %catch (e) { } indicates a TryCatchStatement with the "promise"
prediction.

The previous implementation of using the function to tell the relevant
try-catch apart from inner try-catch blocks will not work for async functions
since these can have inner try-catch blocks inside the same function.

BUG=v8:5167

Committed: https://crrev.com/6d0a4202982529630e7f7e636b25f267b7fe8857
Cr-Commit-Position: refs/heads/master@{#37966}
==========

[commit-bot: I haz the power, 2016-07-22 06:05:04]

Patchset 1 (id:??) landed as
https://crrev.com/6d0a4202982529630e7f7e636b25f267b7fe8857
Cr-Commit-Position: refs/heads/master@{#37966}