Sane asynchronous debugging and stack traces

Sane asynchronous debugging and stack traces

**Debugging**

This CL provides a sane asynchronous debugging experience by tracking
the 'async return call stack' between async functions and awaiters.
By knowing where execution will resume after an async function completes,
we can provide a debugger experience that matches the synchronous experience.

Stepping-in and stepping-out of async functions is now supported.

TODO: Stopping on uncaught exceptions.

Tracking the 'async return call stack' works by adding linkage between
asynchronous methods and their awaiters.

*How does return call stack linkage work?*
Each async and async* function activation returns a Future. When that
Future is awaited on the awaiter sets a field which can be seen from the
async/async* function's closure activation. If you await on the same future
multiple times, the last awaiter wins. When reconstructing the return call
stack, we only look at the immediate Future returned by the async/async*
function.

*Non-linear forking and joining*

Dart allows for forking and joining with Futures. This CL does not handle this
problem. We will still present the illusion that the return call stack is
always linear when it might not actually be.

**Causal stack traces and exceptions**

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

---

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix into the Thread.

Tracking the async return call stack:

- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.

- [x] Filter stack traces to remove async machinery.

Service Protocol changes:

- [x] Send the async call stack along side the sync call stack.

Observatory changes:

- [x] Toggle between async and sync call stack.

Stepping changes:

- [x] Step into support for asynchronous methods.
- [x] Step out support for asynchronous methods.

Debugger changes:

- [x] Refactoring and cleanups in debugger

BUG=

[Cutch, 2017-01-03 17:25:37]

Description was changed from

==========
Sane asynchronous debugging and stack traces

**Debugging**

This CL provides a sane asynchronous debugging experience by tracking
the 'async return call stack' between async functions and awaiters.
By knowing where execution will resume after an async function completes,
we can provide a debugger experience that matches the synchronous experience.

Stepping-in and stepping-out of async functions is now supported.

TODO: Stopping on uncaught exceptions.

Tracking the 'async return call stack' works by adding linkage between
asynchronous methods and their awaiters.

*How does return call stack linkage work?*
Each async and async* function activation returns a Future. When that
Future is awaited on the awaiter sets a field which can be seen from the
async/async* function's closure activation. If you await on the same future
multiple times, the last awaiter wins. When reconstructing the return call
stack, we only look at the immediate Future returned by the async/async*
function.

*Non-linear forking and joining*

Dart allows for forking and joining with Futures. This CL does not handle this
problem. We will still present the illusion that the return call stack is
always linear when it might not actually be.

**Causal stack traces and exceptions**

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

---

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.

Tracking the async return call stack:

- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.

- [x] Filter stack traces to remove async machinery.

Service Protocol changes:

- [x] Send the async call stack along side the sync call stack.

Observatory changes:

- [x] Toggle between async and sync call stack.

Stepping changes:

- [x] Step into support for asynchronous methods.
- [x] Step out support for asynchronous methods.

Debugger changes:

- [x] Refactoring and cleanups in debugger

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

to

==========
Sane asynchronous debugging and stack traces

**Debugging**

This CL provides a sane asynchronous debugging experience by tracking
the 'async return call stack' between async functions and awaiters.
By knowing where execution will resume after an async function completes,
we can provide a debugger experience that matches the synchronous experience.

Stepping-in and stepping-out of async functions is now supported.

TODO: Stopping on uncaught exceptions.

Tracking the 'async return call stack' works by adding linkage between
asynchronous methods and their awaiters.

*How does return call stack linkage work?*
Each async and async* function activation returns a Future. When that
Future is awaited on the awaiter sets a field which can be seen from the
async/async* function's closure activation. If you await on the same future
multiple times, the last awaiter wins. When reconstructing the return call
stack, we only look at the immediate Future returned by the async/async*
function.

*Non-linear forking and joining*

Dart allows for forking and joining with Futures. This CL does not handle this
problem. We will still present the illusion that the return call stack is
always linear when it might not actually be.

**Causal stack traces and exceptions**

This CL improves the stack traces that accompany exceptions. Whenever an
async function is entered, we remember how we got there. This is similar
in spirit to package:stack_trace but the implementation is more efficient
and memory usage can be more easily reasoned about.

---

Tracking causal stack traces:

- [x] Upon entry to an async function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Upon entry to an async* function, capture the synchronous stack trace
prefix and store it into the closure.
- [x] Before returning from an async function, clear the Thread's asynchronous
stack trace.
- [x] After resuming an async function, load the sychronous stack trace prefix
into the Thread.

Tracking the async return call stack:

- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.

- [x] Filter stack traces to remove async machinery.

Service Protocol changes:

- [x] Send the async call stack along side the sync call stack.

Observatory changes:

- [x] Toggle between async and sync call stack.

Stepping changes:

- [x] Step into support for asynchronous methods.
- [x] Step out support for asynchronous methods.

Debugger changes:

- [x] Refactoring and cleanups in debugger

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

[Cutch, 2017-01-03 17:25:37]

johnmccutchan@google.com changed reviewers:
+ asiva@google.com, turnidge@google.com

[Cutch, 2017-03-31 17:16:37]

I've now landed this larger CL as many small CLs.

Closing.