[inspector] introduced stepIntoAsync for chained callbacks

[inspector] introduced stepIntoAsync for chained callbacks

Introduced:
- break location before each .then call if scheduled action is stepInto,
- Debugger.stepIntoAsync method which schedules break at the entry to chained callback,
- "stepIntoAsyncAvailable" property inside of data argument of Debugger.paused notification, this flag is true for break location before Promise.then.

BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org

[kozy, 2017-01-27 20:13:22]

Description was changed from

==========
async-step-in

WIP

BUG=
==========

to

==========
[inspector] proof-of-concept async-step-into for Promises

This CL is uploaded to highlight existing issues (see comments for test
expectations). 

BUG=none
R=yangguo@chromium.org,dgozman@chromium.org
==========

[kozy, 2017-01-27 20:13:22]

kozyatinskiy@chromium.org changed reviewers:
+ dgozman@chromium.org, yangguo@chromium.org

[kozy, 2017-01-27 20:14:38]

Patchset #2 (id:20001) has been deleted

[kozy, 2017-01-27 20:14:44]

Patchset #1 (id:1) has been deleted

[kozy, 2017-01-27 20:54:58]

Inspector part contains implementation of two parts:
- how we can break at the moment of asyncTaskCreated event,
- how we can break on entry to scheduled callback.

Test expectations wit comments highlights current issues that should be
addressed before shipping step-into-async at least for promises.

There three issues and one feature request:
1. [issue] for any reasons break position for assignment located not right after
equal sign but after some part of expression on right side. See comments for
expectations for some proofs. Yang, could it be a case? Or there is other reason
of this strange behavior.
2. [issue] we send async instrumentations for internal promises created inside
Promise.all and Promise.race implementations - it produces additional breaks on
Promise.all call.
3. [feature request] we can break before Promise.prototype.then or setTimeout
call for any reasons - breakpoint, step-next, e.t.c. At this point if
async-stacks are enabled we'd like to silently ignore this break and do
additional step-in which will break on asyncTaskCreated event. Yang proposed
additional argument for v8::Break event which contains function to be called. It
allows inspector to achieve required behavior.

4. [issue] on step-in at the begin of line like promise.then(...).then(...),
next break will happen in next line. As I understood the reason is .then is not
regular JavaScript code and defined in builtin-promises.cc as generated asm
code. I'm not sure do we really want to fix this and we can ship step-into-async
without this fix based on break on asyncTaskCreated and function to be called in
v8::Break event. So based on laser-focus it's low priority.

I'll take a look on first and second and as I know third one is currently on the
Yang's radar :)

Yang and Dmitry, WDYT?

[1]
https://docs.google.com/document/d/1EoyTtP_pgPtEYQdemU3i-LtEzkPdgZBm8WBnPaBhJ...

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
File test/inspector/debugger/async-step-into-for-promise-expected.txt (right):

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:3: Running
test: testPromiseThen
function promiseThen() {
  var resolve1;
  var p1 = new Promise(resolve => resolve1 = resolve);
  debugger;
  var p2 = p1.then(foo1);
  resolve1();
  return p2
}

- first debugger breaks at debugger statement,
- after step-in debugger breaks after "p1" and before dot in next line,
- after step-in debugger breaks at the same position because of
asyncTaskCreated.

Looks like second break happens because of assignment: var p1 = .., locations of
this break looks confusing to me, it should be in between of "=" and "p1".

With additional information about "function to be called" in v8::Break event we
can automatically do additional step-in on second break and show user only first
and third one when function is Promise.then..

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:27: Running
test: testPromiseThenWithoutAssignment
function promiseThenWithoutAssignment() {
  var nextTest;
  var testPromise = new Promise(resolve => nextTest = resolve);

  var resolve1;
  var p1 = new Promise(resolve => resolve1 = resolve);
  debugger;
  p1.then(foo1).then(nextTest);
  resolve1();
  return testPromise;
}

- first debugger breaks at debugger stmt;
- second time at begin of next line;
- third time before .then call because of asyncTaskCreated;

Here we could not automatically skip one step in between but we don't really
want to skip it because it happens before "calculating" p1 variable.

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:51: Running
test: testPromiseAll
This test case highlight one more issue.

function promiseAll() {
  var resolve1;
  var resolve2;
  var p1 = new Promise(resolve => resolve1 = resolve);
  var p2 = new Promise(resolve => resolve2 = resolve);
  debugger;
  var p3 = Promise.all([ p1, p2 ]).then(foo1);
  resolve1();
  resolve2();
  return p3;
}

- first break at debugger stmt;
- second break right after "Promise.all([ p1, p2 ])" looks weird and I think we
continue incorrectly calculate assignment location;
- third break at dot after "Promise", before all call,
- two following asyncTaskCreated breaks are related to instrumentation which
called for internal promises inside Promise.all implementation, we shouldn't
send async instrumentation for them.
- one more break after "Promise.all([ p1, p2 ])." before actual "then" call, we
could skip this break in the way described before. I think here we break before
.then call because Promise.all is regular JS function declared in promise.js.
- break on asyncTaskCreated - good one.

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:96: Running
test: testPromiseAllWithoutAssignment
function promiseAllWithoutAssignment() {
  var nextTest;
  var testPromise = new Promise(resolve => nextTest = resolve);

  var resolve1;
  var resolve2;
  var p1 = new Promise(resolve => resolve1 = resolve);
  var p2 = new Promise(resolve => resolve2 = resolve);

  debugger;
  Promise.all([ p1, p2 ]).then(foo1).then(nextTest);
  resolve1();
  resolve2();
  return testPromise;
}

WIthout assignment we breaks:
- at debugger statement;
- at the begin of next line;
- on two internal asyncTaskCreated instrumentation call;
- on real asyncTaskCreated instrumentation call.

Here we don't break before .then call after Promise.all without asyncTaskCreated
instrumentation. By module of two internal asyncTaskCreated instrumentation
works perfect.

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:133: Running
test: testPromiseThen
FYI: following test expectations show current step-int behavior with promises
and assignments.

[dgozman, 2017-01-27 23:59:22]

I guess most of the questions are for Yang, but here are my thoughts:

- It would be great to pause before .then, as I'd expect that when doing
step-in. Not a high-priority, but I think it blocks my third bullet :(

- If we can avoid doing "additional step-in", that would be awesome from an
implementation standpoint :)

- I don't really like breaking on asyncTaskCreated, as that's not what user
expects. It would be better instead to pause regularly before a function call,
and based on the function to be called decide whether it will cause an async
task or not. WDYT? Is that feasible?

[kozy, 2017-01-28 00:12:42]

Uploaded to this CL fix for redundant asyncTaskCreated events from Promise.all
and Promise.race. They occur because Promise.all and Promise.race implementation
uses .then internally. To build correct asynchronous stack trace we need to
instrument these internal promises but ignore them as potential break point.
Added flag to asyncTaskCreated event. It doesn't look superb to me so..

On 2017/01/27 23:59:22, dgozman wrote:
> I guess most of the questions are for Yang, but here are my thoughts:
> 
> - It would be great to pause before .then, as I'd expect that when doing
> step-in. Not a high-priority, but I think it blocks my third bullet :(
> 
> - If we can avoid doing "additional step-in", that would be awesome from an
> implementation standpoint :)
> 
> - I don't really like breaking on asyncTaskCreated, as that's not what user
> expects. It would be better instead to pause regularly before a function call,
> and based on the function to be called decide whether it will cause an async
> task or not. WDYT? Is that feasible?

To achieve all your points we need following:
- function to be called in v8::Break event,
- break before any function in expression like foo1().foo2().foo3(), even if
this function are builtin or generated in asm code, sounds like it should be
possible. Additionally it allows us just ignore fact that Promise.all
implemented with .then calls since user are not able to reach point before
internal .then call.
Yang, WDYT?

[kozy, 2017-01-28 21:36:10]

I think that problem with stepping over assignment with more then one functions
call is located around this line [1].

For any reasons if there are more then one function call in the row, redundant
break position after assignment appears. Yang, WDYT? You added this code a long
time ago [2].

[1]
https://cs.chromium.org/chromium/src/v8/src/parsing/pattern-rewriter.cc?rcl=0...
[2]
https://codereview.chromium.org/1768973002/diff/1/src/parsing/pattern-rewrite...

[Yang, 2017-01-30 13:30:15]

https://codereview.chromium.org/2655253004/diff/60001/src/debug/debug.h
File src/debug/debug.h (right):

https://codereview.chromium.org/2655253004/diff/60001/src/debug/debug.h#newco...
src/debug/debug.h:629: bool non_breakable_async_events_;
Can we have a comment here?

https://codereview.chromium.org/2655253004/diff/60001/src/js/promise.js
File src/js/promise.js (right):

https://codereview.chromium.org/2655253004/diff/60001/src/js/promise.js#newco...
src/js/promise.js:52: %DebugSetNonBreakableAsyncEvents(true);
This is not particular elegant. Especially if PromiseAll is called recursively.

I think what you should rather do is to mark the SharedFunctionInfo for
PromiseAll and PromiseRace with a new debugger_hints flag. When you then iterate
the stack, and find a function with that flag, you know that a non-breakable
async event is on-going.

[kozy, 2017-01-30 16:58:00]

Yang, could you take a look on other points in comments to this CL?

https://codereview.chromium.org/2655253004/diff/60001/src/debug/debug.h
File src/debug/debug.h (right):

https://codereview.chromium.org/2655253004/diff/60001/src/debug/debug.h#newco...
src/debug/debug.h:629: bool non_breakable_async_events_;
On 2017/01/30 13:30:14, Yang wrote:
> Can we have a comment here?

Removed.

https://codereview.chromium.org/2655253004/diff/60001/src/js/promise.js
File src/js/promise.js (right):

https://codereview.chromium.org/2655253004/diff/60001/src/js/promise.js#newco...
src/js/promise.js:52: %DebugSetNonBreakableAsyncEvents(true);
On 2017/01/30 13:30:14, Yang wrote:
> This is not particular elegant. Especially if PromiseAll is called
recursively.
> 
> I think what you should rather do is to mark the SharedFunctionInfo for
> PromiseAll and PromiseRace with a new debugger_hints flag. When you then
iterate
> the stack, and find a function with that flag, you know that a non-breakable
> async event is on-going.

Done.

[Yang, 2017-01-30 19:40:34]

LGTM. Though I'm not familiar enough with the inspector so please wait for
Dmitry's comments.

https://codereview.chromium.org/2655253004/diff/80001/src/debug/debug.cc
File src/debug/debug.cc (right):

https://codereview.chromium.org/2655253004/diff/80001/src/debug/debug.cc#newc...
src/debug/debug.cc:1953: if (!frame->HasInlinedFrames()) {
We can remove this check. GetFunctions should work fine for non-inlining frames
too. In fact, I think we can just inline this function into its call site.

https://codereview.chromium.org/2655253004/diff/80001/src/inspector/v8-debugg...
File src/inspector/v8-debugger.cc (right):

https://codereview.chromium.org/2655253004/diff/80001/src/inspector/v8-debugg...
src/inspector/v8-debugger.cc:612: void* task = reinterpret_cast<void*>(id * 2 +
1);
why is this void* and not intptr_t?

https://codereview.chromium.org/2655253004/diff/80001/src/inspector/v8-debugg...
src/inspector/v8-debugger.cc:617: // We don't need to pass context group id here
because we gets this callback
s/gets/get/

[Yang, 2017-01-30 20:04:32]

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
File test/inspector/debugger/async-step-into-for-promise-expected.txt (right):

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:3: Running
test: testPromiseThen
On 2017/01/27 20:54:58, kozy wrote:
> function promiseThen() {
>   var resolve1;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   debugger;
>   var p2 = p1.then(foo1);
>   resolve1();
>   return p2
> }
> 
> - first debugger breaks at debugger statement,
> - after step-in debugger breaks after "p1" and before dot in next line,
> - after step-in debugger breaks at the same position because of
> asyncTaskCreated.
> 
> Looks like second break happens because of assignment: var p1 = .., locations
of
> this break looks confusing to me, it should be in between of "=" and "p1".
> 
> With additional information about "function to be called" in v8::Break event
we
> can automatically do additional step-in on second break and show user only
first
> and third one when function is Promise.then..

I think this is expected. The reason is that we break at statement positions,
calls and returns. The assignment happens after the call to .then. However, I
think there is some weirdness because of variable declaration "var p1", and the
assignment immediately after.

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:27: Running
test: testPromiseThenWithoutAssignment
On 2017/01/27 20:54:58, kozy wrote:
> function promiseThenWithoutAssignment() {
>   var nextTest;
>   var testPromise = new Promise(resolve => nextTest = resolve);
> 
>   var resolve1;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   debugger;
>   p1.then(foo1).then(nextTest);
>   resolve1();
>   return testPromise;
> }
> 
> - first debugger breaks at debugger stmt;
> - second time at begin of next line;
> - third time before .then call because of asyncTaskCreated;
> 
> Here we could not automatically skip one step in between but we don't really
> want to skip it because it happens before "calculating" p1 variable.

Let's not skip. We are stopping before the statement.

https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
test/inspector/debugger/async-step-into-for-promise-expected.txt:51: Running
test: testPromiseAll
On 2017/01/27 20:54:58, kozy wrote:
> This test case highlight one more issue.
> 
> function promiseAll() {
>   var resolve1;
>   var resolve2;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   var p2 = new Promise(resolve => resolve2 = resolve);
>   debugger;
>   var p3 = Promise.all([ p1, p2 ]).then(foo1);
>   resolve1();
>   resolve2();
>   return p3;
> }
> 
> - first break at debugger stmt;
> - second break right after "Promise.all([ p1, p2 ])" looks weird and I think
we
> continue incorrectly calculate assignment location;
> - third break at dot after "Promise", before all call,
> - two following asyncTaskCreated breaks are related to instrumentation which
> called for internal promises inside Promise.all implementation, we shouldn't
> send async instrumentation for them.
> - one more break after "Promise.all([ p1, p2 ])." before actual "then" call,
we
> could skip this break in the way described before. I think here we break
before
> .then call because Promise.all is regular JS function declared in promise.js.
> - break on asyncTaskCreated - good one.

These issues seem to be unrelated to async stepping, but rather related to
assignment and function calls. Can you file a bug with a small repro so that I
can take a look?

[Yang, 2017-01-31 08:43:48]

On 2017/01/27 20:54:58, kozy wrote:
> Inspector part contains implementation of two parts:
> - how we can break at the moment of asyncTaskCreated event,
> - how we can break on entry to scheduled callback.
> 
> Test expectations wit comments highlights current issues that should be
> addressed before shipping step-into-async at least for promises.
> 
> There three issues and one feature request:
> 1. [issue] for any reasons break position for assignment located not right
after
> equal sign but after some part of expression on right side. See comments for
> expectations for some proofs. Yang, could it be a case? Or there is other
reason
> of this strange behavior.

This is reported as https://bugs.chromium.org/p/v8/issues/detail?id=5909, and
unrelated to actual async stepping, right? I'll investigate that soon.

> 2. [issue] we send async instrumentations for internal promises created inside
> Promise.all and Promise.race implementations - it produces additional breaks
on
> Promise.all call.

This is already solved with the promise-all-or-race check, right?

> 3. [feature request] we can break before Promise.prototype.then or setTimeout
> call for any reasons - breakpoint, step-next, e.t.c. At this point if
> async-stacks are enabled we'd like to silently ignore this break and do
> additional step-in which will break on asyncTaskCreated event. Yang proposed
> additional argument for v8::Break event which contains function to be called.
It
> allows inspector to achieve required behavior.

What I currently have in mind for break-on-entry is to simply replicate the
current pauseOnNextStatement behavior, but without using debug interrupts. Upon
function entry, we will check whether the function is subject to
debugging/blackboxing, and flood it with break points so that we can break in
the function itself asap.

But that does not help with your use case here, does it? What you need is to
actually break *before* entering the function, because we cannot break inside
Promise.prototype.then or setTimeout, right? Is this an one-off event, in
certain situations, or does the inspector require an event for every function
entry as long as it is enabled? For this, we should implement a new debug event,
and not mix it with the break event. To fire this event during stepping should
be fairly simple to implement, but using break points for this is more
complicated.

Maybe this could actually be solved differently if I implement setting break
points on API function callbacks
(https://bugs.chromium.org/p/v8/issues/detail?id=178), so that you can set a
break point to Promise.prototype.then and setTimeout? But then, wouldn't it also
work to simply adding hooks to Promise.prototype.then and setTimeout?

> 
> 4. [issue] on step-in at the begin of line like promise.then(...).then(...),
> next break will happen in next line. As I understood the reason is .then is
not
> regular JavaScript code and defined in builtin-promises.cc as generated asm
> code. I'm not sure do we really want to fix this and we can ship
step-into-async
> without this fix based on break on asyncTaskCreated and function to be called
in
> v8::Break event. So based on laser-focus it's low priority.
> 
> I'll take a look on first and second and as I know third one is currently on
the
> Yang's radar :)
> 
> Yang and Dmitry, WDYT?
> 
> [1]
>
https://docs.google.com/document/d/1EoyTtP_pgPtEYQdemU3i-LtEzkPdgZBm8WBnPaBhJ...
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> File test/inspector/debugger/async-step-into-for-promise-expected.txt (right):
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> test/inspector/debugger/async-step-into-for-promise-expected.txt:3: Running
> test: testPromiseThen
> function promiseThen() {
>   var resolve1;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   debugger;
>   var p2 = p1.then(foo1);
>   resolve1();
>   return p2
> }
> 
> - first debugger breaks at debugger statement,
> - after step-in debugger breaks after "p1" and before dot in next line,
> - after step-in debugger breaks at the same position because of
> asyncTaskCreated.
> 
> Looks like second break happens because of assignment: var p1 = .., locations
of
> this break looks confusing to me, it should be in between of "=" and "p1".
> 
> With additional information about "function to be called" in v8::Break event
we
> can automatically do additional step-in on second break and show user only
first
> and third one when function is Promise.then..
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> test/inspector/debugger/async-step-into-for-promise-expected.txt:27: Running
> test: testPromiseThenWithoutAssignment
> function promiseThenWithoutAssignment() {
>   var nextTest;
>   var testPromise = new Promise(resolve => nextTest = resolve);
> 
>   var resolve1;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   debugger;
>   p1.then(foo1).then(nextTest);
>   resolve1();
>   return testPromise;
> }
> 
> - first debugger breaks at debugger stmt;
> - second time at begin of next line;
> - third time before .then call because of asyncTaskCreated;
> 
> Here we could not automatically skip one step in between but we don't really
> want to skip it because it happens before "calculating" p1 variable.
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> test/inspector/debugger/async-step-into-for-promise-expected.txt:51: Running
> test: testPromiseAll
> This test case highlight one more issue.
> 
> function promiseAll() {
>   var resolve1;
>   var resolve2;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   var p2 = new Promise(resolve => resolve2 = resolve);
>   debugger;
>   var p3 = Promise.all([ p1, p2 ]).then(foo1);
>   resolve1();
>   resolve2();
>   return p3;
> }
> 
> - first break at debugger stmt;
> - second break right after "Promise.all([ p1, p2 ])" looks weird and I think
we
> continue incorrectly calculate assignment location;
> - third break at dot after "Promise", before all call,
> - two following asyncTaskCreated breaks are related to instrumentation which
> called for internal promises inside Promise.all implementation, we shouldn't
> send async instrumentation for them.
> - one more break after "Promise.all([ p1, p2 ])." before actual "then" call,
we
> could skip this break in the way described before. I think here we break
before
> .then call because Promise.all is regular JS function declared in promise.js.
> - break on asyncTaskCreated - good one.
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> test/inspector/debugger/async-step-into-for-promise-expected.txt:96: Running
> test: testPromiseAllWithoutAssignment
> function promiseAllWithoutAssignment() {
>   var nextTest;
>   var testPromise = new Promise(resolve => nextTest = resolve);
> 
>   var resolve1;
>   var resolve2;
>   var p1 = new Promise(resolve => resolve1 = resolve);
>   var p2 = new Promise(resolve => resolve2 = resolve);
> 
>   debugger;
>   Promise.all([ p1, p2 ]).then(foo1).then(nextTest);
>   resolve1();
>   resolve2();
>   return testPromise;
> }
> 
> WIthout assignment we breaks:
> - at debugger statement;
> - at the begin of next line;
> - on two internal asyncTaskCreated instrumentation call;
> - on real asyncTaskCreated instrumentation call.
> 
> Here we don't break before .then call after Promise.all without
asyncTaskCreated
> instrumentation. By module of two internal asyncTaskCreated instrumentation
> works perfect.
> 
>
https://codereview.chromium.org/2655253004/diff/40001/test/inspector/debugger...
> test/inspector/debugger/async-step-into-for-promise-expected.txt:133: Running
> test: testPromiseThen
> FYI: following test expectations show current step-int behavior with promises
> and assignments.

[kozy, 2017-01-31 16:22:05]

On 2017/01/31 08:43:48, Yang wrote:
> On 2017/01/27 20:54:58, kozy wrote:
> > Inspector part contains implementation of two parts:
> > - how we can break at the moment of asyncTaskCreated event,
> > - how we can break on entry to scheduled callback.
> > 
> > Test expectations wit comments highlights current issues that should be
> > addressed before shipping step-into-async at least for promises.
> > 
> > There three issues and one feature request:
> > 1. [issue] for any reasons break position for assignment located not right
> after
> > equal sign but after some part of expression on right side. See comments for
> > expectations for some proofs. Yang, could it be a case? Or there is other
> reason
> > of this strange behavior.
> 
> This is reported as https://bugs.chromium.org/p/v8/issues/detail?id=5909, and
> unrelated to actual async stepping, right? I'll investigate that soon.

Yes.

> > 2. [issue] we send async instrumentations for internal promises created
inside
> > Promise.all and Promise.race implementations - it produces additional breaks
> on
> > Promise.all call.

Yes, but we could avoid it in case if implement "Solution 1" from
https://docs.google.com/document/d/15Z3I_Q0dkzZuhgUtIhfDXHzT-3WsaV44MA9SM8dry...
since we wouldn't be able to step-into over internal .then call. It sounds more
elegant to me.
 
> > 3. [feature request] we can break before Promise.prototype.then or
setTimeout
> > call for any reasons - breakpoint, step-next, e.t.c. At this point if
> > async-stacks are enabled we'd like to silently ignore this break and do
> > additional step-in which will break on asyncTaskCreated event. Yang proposed
> > additional argument for v8::Break event which contains function to be
called.
> It
> > allows inspector to achieve required behavior.
> What I currently have in mind for break-on-entry is to simply replicate the
> current pauseOnNextStatement behavior, but without using debug interrupts.
Upon
> function entry, we will check whether the function is subject to
> debugging/blackboxing, and flood it with break points so that we can break in
> the function itself asap.
> 
> But that does not help with your use case here, does it? What you need is to
> actually break *before* entering the function, because we cannot break inside
> Promise.prototype.then or setTimeout, right? Is this an one-off event, in
> certain situations, or does the inspector require an event for every function
> entry as long as it is enabled? For this, we should implement a new debug
event,
> and not mix it with the break event. To fire this event during stepping should
> be fairly simple to implement, but using break points for this is more
> complicated.

Inspector has list of native functions that could produce async events and on
inspector side we'd like to be able to break before call to each of them during
stepping by step-in action and has reference to function-to-be-called on regular
v8::Break event if we break before native call for other reasons (e.g.
breakpoint or step-next from previous line).
I tried to describe suggested approach in:
https://docs.google.com/document/d/15Z3I_Q0dkzZuhgUtIhfDXHzT-3WsaV44MA9SM8dry...

> Maybe this could actually be solved differently if I implement setting break
> points on API function callbacks
> (https://bugs.chromium.org/p/v8/issues/detail?id=178), so that you can set a
> break point to Promise.prototype.then and setTimeout? But then, wouldn't it
also
> work to simply adding hooks to Promise.prototype.then and setTimeout?

Mentioned this in the doc.

[kozy, 2017-02-15 00:57:38]

Description was changed from

==========
[inspector] proof-of-concept async-step-into for Promises

This CL is uploaded to highlight existing issues (see comments for test
expectations). 

BUG=none
R=yangguo@chromium.org,dgozman@chromium.org
==========

to

==========
[inspector] introduced stepIntoAsync for chained callbacks

Introduced:
- break location before each .then call if scheduled action is stepInto,
- Debugger.stepIntoAsync method which schedules break at the entry to chained
callback,
- "stepIntoAsyncAvailable" property inside of data argument of Debugger.paused
notification, this flag is true for break location before Promise.then.

BUG=chromium:432469
R=yangguo@chromium.org,dgozman@chromium.org
==========

[kozy, 2017-02-15 01:00:54]

Dmitry and Yang, please take a look!

https://codereview.chromium.org/2655253004/diff/80001/src/debug/debug.cc
File src/debug/debug.cc (right):

https://codereview.chromium.org/2655253004/diff/80001/src/debug/debug.cc#newc...
src/debug/debug.cc:1953: if (!frame->HasInlinedFrames()) {
On 2017/01/30 19:40:33, Yang wrote:
> We can remove this check. GetFunctions should work fine for non-inlining
frames
> too. In fact, I think we can just inline this function into its call site.

Done.

https://codereview.chromium.org/2655253004/diff/80001/src/inspector/v8-debugg...
File src/inspector/v8-debugger.cc (right):

https://codereview.chromium.org/2655253004/diff/80001/src/inspector/v8-debugg...
src/inspector/v8-debugger.cc:617: // We don't need to pass context group id here
because we gets this callback
On 2017/01/30 19:40:33, Yang wrote:
> s/gets/get/

Done.

[kozy, 2017-02-15 21:48:03]

Frontend part: https://codereview.chromium.org/2696253002

[kozy, 2017-02-17 16:52:44]

Most issues which we found yesterday are fixed.
One left: you need to make additional stepInto after stepOut from constructor or
in case of createPromise().then(foo). Looks big enough to think about
alternatives.
1. We can break in .then only when current stepping action is stepOver.
Advantage: always easy to go to next .then callback - you don't need to do
stepInto createPromise function and then press stepOut, just one click to
stepOver.
Disadvantage: stepOver will break more often then stepInto on expression like
promise.then(..).then(..).then(..).

2. We can introduce break location before function call and report
function-about-to-be-called in v8::Break event. It'll solve all use cases
including setTimeout. I'll try to do it today.

I think that ideal solution is some mix of 1 and 2. We report function
about-to-be-called in v8::Break and tune break location in expression like
createPromise().then(..).then(..). Additionally we add break before .then calls
during stepOver action to provide easy way to go to inspected chained callback.