v8/test/debugger/debug/es6/debug-stepin-microtasks.js

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

80 lines
2.1 KiB
JavaScript
Raw Normal View History

// Copyright 2014 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
Debug = debug.Debug
var exception = null;
var break_count = 0;
[debugger] tuned StepNext and StepOut at return position Proposed behaviour: - StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side); - StepOut at return position go into next non-current function call. We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners). New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test): - let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another: var foo = () => 1; callAll(foo, foo, () => 2); If we break inside of first call of function foo. Then on.. ..StepNext - we're able to reach second call of function foo, ..StepOut - we're able to reach () => 2 call. - let's consider case with native function: [1,2,3].map(x => x * 2) If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call. Implementation details: - when we request break we schedule step-in function call for any step action at return position and for step-in at any position, - when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call, - when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break. Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit BUG=v8:6118,chromium:583193 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2758483002 Cr-Commit-Position: refs/heads/master@{#44028}
2017-03-22 14:16:18 +00:00
const expected_breaks = 10;
function listener(event, exec_state, event_data, data) {
try {
if (event == Debug.DebugEvent.Break) {
assertTrue(exec_state.frameCount() != 0, "FAIL: Empty stack trace");
var source = exec_state.frame(0).sourceLineText();
print("paused at: " + source);
assertTrue(source.indexOf("// Break " + break_count + ".") > 0,
"Unexpected pause at: " + source + "\n" +
"Expected: // Break " + break_count + ".");
if (source.indexOf("StepOver.") !== -1) {
exec_state.prepareStep(Debug.StepAction.StepOver);
} else if (source.indexOf("StepOut.") !== -1) {
exec_state.prepareStep(Debug.StepAction.StepOut);
} else {
exec_state.prepareStep(Debug.StepAction.StepInto);
}
++break_count;
}
} catch (e) {
exception = e;
print(e, e.stack);
}
};
Debug.setListener(listener);
Promise.resolve(42)
.then(promise1)
.then(Object) // Should skip stepping into native.
.then(Boolean) // Should skip stepping into native.
.then(promise2)
.catch(promise3)
.then(promise4)
.catch(function(e) {
%AbortJS("FAIL: uncaught exception " + e);
});
function promise1() {
debugger; // Break 0.
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
return exception || 1 // Break 1.
; // Break 2. StepOver.
}
function promise2() {
throw new Error; // Break 3.
}
function promise3() {
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
return break_count // Break 4.
; // Break 5.
}
function promise4() {
finalize(); // Break 6. StepOver.
[inspector] improve return position of explicit return in non-async function Goal of this CL: explicit return from non-async function has position after return expression as return position (will unblock [1]). BytecodeArrayBuilder has SetStatementPosition and SetExpressionPosition methods. If one of these methods is called then next generated bytecode will get passed position. It's general treatment for most cases. Unfortunately it doesn't work for Returns: - debugger requires source positions exactly on kReturn bytecode in stepping implementation, - BytecodeGenerator::BuildReturn and BytecodeGenerator::BuildAsyncReturn generates more then one bytecode and general solution will put return position on first generated bytecode, - it's not easy to split BuildReturn function into two parts to allow something like following in BytecodeGenerator::VisitReturnStatement since generated bytecodes are actually controlled by execution_control(). ..->BuildReturnPrologue(); ..->SetReturnPosition(stmt); ..->Return(); In this CL we pass ReturnStatement through ExecutionControl and use it for position when we emit return bytecode right here. So this CL only will improve return position for returns inside of non-async functions, I'll address async functions later. [1] https://chromium-review.googlesource.com/c/543161/ Change-Id: Iede512c120b00c209990bf50c20e7d23dc0d65db Reviewed-on: https://chromium-review.googlesource.com/560738 Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#46687}
2017-07-14 17:50:09 +00:00
return 0 // Break 7.
; // Break 8. StepOut.
}
function finalize() {
Promise.resolve().then(function() {
[debugger] tuned StepNext and StepOut at return position Proposed behaviour: - StepNext at return position go into next function call (no changes with current behavior, but implemented in v8::Debug instead of hack on inspector side); - StepOut at return position go into next non-current function call. We need this to have better stepping in cases with native functions, blackboxed functions and/or different embedder calls (e.g. event listeners). New behavior could be illustrated with two examples (for more see stepping-with-natives-and-frameworks test): - let's assume that we've blackboxed callAll function, this function just takes its arguments and call one after another: var foo = () => 1; callAll(foo, foo, () => 2); If we break inside of first call of function foo. Then on.. ..StepNext - we're able to reach second call of function foo, ..StepOut - we're able to reach () => 2 call. - let's consider case with native function: [1,2,3].map(x => x * 2) If we break inside of first callback call, then with StepNext we can iterate through all calls of callback, with StepOut we go to next statement after .map call. Implementation details: - when we request break we schedule step-in function call for any step action at return position and for step-in at any position, - when we request StepOut at return position - we mark current function as needed-to-be-ignored inside of PrepareStepIn(function) call, - when we request StepOut at not return position - we set break at return position and ask debugger to just repeat last step action on next stepping-related break. Design doc: https://docs.google.com/document/d/1ihXHOIhP_q-fJCA0e2EiXz_Zr3B08KMjaPifcaqZ60Q/edit BUG=v8:6118,chromium:583193 R=dgozman@chromium.org,yangguo@chromium.org Review-Url: https://codereview.chromium.org/2758483002 Cr-Commit-Position: refs/heads/master@{#44028}
2017-03-22 14:16:18 +00:00
if (expected_breaks !== break_count) { // Break 9. StepOut.
%AbortJS("FAIL: expected <" + expected_breaks + "> breaks instead of <" +
break_count + ">");
}
if (exception !== null) {
%AbortJS("FAIL: exception: " + exception);
}
});
}