DevTools: Support asynchronous call stacks on backend.

Source/devtools/protocol.json

Index: Source/devtools/protocol.json
diff --git a/Source/devtools/protocol.json b/Source/devtools/protocol.json
index f7e192d046105c96f28751d0b02849c815f54585..03b6b926ada75b8f900cc7b6c02f3f90f6400d18 100644
--- a/Source/devtools/protocol.json
+++ b/Source/devtools/protocol.json
@@ -2958,7 +2958,8 @@
                     { "name": "location", "$ref": "Location", "description": "Location in the source code." },
                     { "name": "scopeChain", "type": "array", "items": { "$ref": "Scope" }, "description": "Scope chain for this call frame." },
                     { "name": "this", "$ref": "Runtime.RemoteObject", "description": "<code>this</code> object for this call frame." },
-                    { "name": "returnValue", "$ref": "Runtime.RemoteObject", "optional": true, "hidden": true, "description": "The value being returned, if the function is at return point." }
+                    { "name": "returnValue", "$ref": "Runtime.RemoteObject", "optional": true, "hidden": true, "description": "The value being returned, if the function is at return point." },
+                    { "name": "asyncCallFrames", "type": "array", "items": { "$ref": "CallFrame" }, "optional": true, "hidden": true, "description": "Asynchronous call stack, if any." }

[yurys, 2013/11/20 14:07:57]

Why is it property on CallFrame, I believe it should be another parameter on
"paused" event.

[aandrey, 2013/11/20 15:20:02]

Here is the list of commands and events that return debugger callFrames:

Debugger.setScriptSource
Debugger.restartFrame
Debugger.getBacktrace
Debugger.paused

In all of them we'd like to send async stacks.

Besides, should you want to return it separately, it will be of type
{Array.<Array.<CallFrame>>} - quite complex and I doubt our code generator
supports this at the moment.

Ideally we should have created a Debugger.StackTrace class as we did for the
Console.StackTrace. If we had done it, this is where the async call frames would
live.

To preserve the backward compatibility, this is the best solution I could think
of.

[yurys, 2013/11/28 10:35:41]

I'd rather add explicit async call stack property there. asyncCallFrames
property on CallFrame looks very confusing.
To preserve backward compatibility you could use Debugger.StackTrace for async
call stacks only.

                 ],
                 "description": "JavaScript call frame. Array of call frames form the call stack."
             },
@@ -3248,6 +3249,14 @@
                 ],
                 "hidden": true,
                 "description": "Makes backend skip steps in the sources with names matching given pattern. VM will try leave blacklisted scripts by performing 'step in' several times, finally resorting to 'step out' if unsuccessful."
+            },
+            {
+                "name": "enableAsyncCallStacks",

[yurys, 2013/11/20 01:23:43]

setAsyncCallStackDepth?

[aandrey, 2013/11/20 15:20:02]

Done.

+                "parameters": [
+                    { "name": "maxDepth", "type": "integer", "description": "Maximum depth of async call stacks. Setting <code>0</code> will effectively disable async call stacks (default)." }
+                ],
+                "hidden": true,
+                "description": "Enables or disables async call stacks tracking."
             }
         ],
         "events": [