v8/test/inspector/debugger/get-possible-breakpoints-expected.txt

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

285 lines
8.2 KiB
Plaintext
Raw Normal View History

Test for Debugger.getPossibleBreakpoints
Running test: getPossibleBreakpointsInRange
Test start.scriptId != end.scriptId.
{
error : {
code : -32000
message : Locations should contain the same scriptId
}
id : <messageId>
}
Test not existing scriptId.
{
error : {
code : -32000
message : Script not found
}
id : <messageId>
}
Test end < start.
function foo(){ return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test empty range in first line.
function foo(){ return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test one character range in first line.
function foo(){ #return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test empty range in not first line.
function foo(){ return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test one character range in not first line.
function foo(){ return Promise.resolve(); }
function boo(){ #return Promise.resolve().then(() => 42); }
Test end is undefined
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ #return Promise.#resolve().#then(() => #42#);# }
#
Test end.lineNumber > scripts.lineCount()
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ #return Promise.#resolve().#then(() => #42#);# }
Test one string
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ return Promise.resolve().then(() => 42); }
Test end.columnNumber > end.line.length(), should be the same as previous.
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ return Promise.resolve().then(() => 42); }
Running test: getPossibleBreakpointsInArrow
function foo() { #return Promise.#resolve().#then(() => #239#).#then(() => #42#).#then(() => #() => #42#)# }#
Running test: arrowFunctionFirstLine
function foo1() { #Promise.#resolve().#then(() => #42#) #}
function foo2() { Promise.resolve().then(() => 42) }
paused in foo1
function foo1() { ^Promise.resolve().then(() => 42) }
function foo2() { Promise.resolve().then(() => 42) }
paused in foo1
function foo1() { Promise.^resolve().then(() => 42) }
function foo2() { Promise.resolve().then(() => 42) }
paused in foo1
function foo1() { Promise.resolve().^then(() => 42) }
function foo2() { Promise.resolve().then(() => 42) }
paused in foo1
function foo1() { Promise.resolve().then(() => 42) ^}
function foo2() { Promise.resolve().then(() => 42) }
paused in Promise.resolve.then
function foo1() { Promise.resolve().then(() => ^42) }
function foo2() { Promise.resolve().then(() => 42) }
paused in Promise.resolve.then
function foo1() { Promise.resolve().then(() => 42^) }
function foo2() { Promise.resolve().then(() => 42) }
Running test: arrowFunctionOnPause
#debugger; function foo3() { #Promise.#resolve().#then(() => #42#) #}
function foo4() { #Promise.#resolve().#then(() => #42#) #};
#foo3();
#foo4();#
paused in
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
^foo3();
foo4();
paused in foo3
debugger; function foo3() { ^Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in foo3
debugger; function foo3() { Promise.^resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in foo3
debugger; function foo3() { Promise.resolve().^then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in foo3
debugger; function foo3() { Promise.resolve().then(() => 42) ^}
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
^foo4();
paused in foo4
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { ^Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in foo4
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.^resolve().then(() => 42) };
foo3();
foo4();
paused in foo4
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().^then(() => 42) };
foo3();
foo4();
paused in foo4
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) ^};
foo3();
foo4();
paused in
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();^
paused in Promise.resolve.then
debugger; function foo3() { Promise.resolve().then(() => ^42) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in Promise.resolve.then
debugger; function foo3() { Promise.resolve().then(() => 42^) }
function foo4() { Promise.resolve().then(() => 42) };
foo3();
foo4();
paused in Promise.resolve.then
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => ^42) };
foo3();
foo4();
paused in Promise.resolve.then
debugger; function foo3() { Promise.resolve().then(() => 42) }
function foo4() { Promise.resolve().then(() => 42^) };
foo3();
foo4();
Running test: getPossibleBreakpointsInRangeWithOffset
Test empty range in first line.
function foo(){ return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test one character range in first line.
function foo(){ #return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test empty range in not first line.
function foo(){ return Promise.resolve(); }
function boo(){ return Promise.resolve().then(() => 42); }
Test one character range in not first line.
function foo(){ return Promise.resolve(); }
function boo(){ #return Promise.resolve().then(() => 42); }
Test end is undefined
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ #return Promise.#resolve().#then(() => #42#);# }
#
Test end.lineNumber > scripts.lineCount()
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ #return Promise.#resolve().#then(() => #42#);# }
Test one string
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ return Promise.resolve().then(() => 42); }
Test end.columnNumber > end.line.length(), should be the same as previous.
[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
function foo(){ #return Promise.#resolve();# }
function boo(){ return Promise.resolve().then(() => 42); }
Running test: withOffset
function foo5() { #Promise.#resolve().#then(() => #42#) #}
function foo6() { #Promise.#resolve().#then(() => #42#) #}
#
paused in foo5
function foo5() { ^Promise.resolve().then(() => 42) }
function foo6() { Promise.resolve().then(() => 42) }
paused in foo5
function foo5() { Promise.^resolve().then(() => 42) }
function foo6() { Promise.resolve().then(() => 42) }
paused in foo5
function foo5() { Promise.resolve().^then(() => 42) }
function foo6() { Promise.resolve().then(() => 42) }
paused in foo5
function foo5() { Promise.resolve().then(() => 42) ^}
function foo6() { Promise.resolve().then(() => 42) }
paused in foo6
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { ^Promise.resolve().then(() => 42) }
paused in foo6
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { Promise.^resolve().then(() => 42) }
paused in foo6
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { Promise.resolve().^then(() => 42) }
paused in foo6
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { Promise.resolve().then(() => 42) ^}
paused in Promise.resolve.then
function foo5() { Promise.resolve().then(() => ^42) }
function foo6() { Promise.resolve().then(() => 42) }
paused in Promise.resolve.then
function foo5() { Promise.resolve().then(() => 42^) }
function foo6() { Promise.resolve().then(() => 42) }
paused in Promise.resolve.then
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { Promise.resolve().then(() => ^42) }
paused in Promise.resolve.then
function foo5() { Promise.resolve().then(() => 42) }
function foo6() { Promise.resolve().then(() => 42^) }
Running test: arrowFunctionReturn
#() => #239#
#
function foo() { function boo() { #return 239# } #}
#
#() => { #239 #}
#
function foo() { #239 #}
#
#() => #239#
#() => { #return 239# }#
Running test: argumentsAsCalls
function foo(){#}
function boo(){#}
function main(f1,f2){#}
#main(#foo(), #boo());
#