v8/test/debugger/debugger.status

96 lines
3.7 KiB
Plaintext
Raw Normal View History

# Copyright 2016 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.
[
[ALWAYS, {
# All tests in the bug directory are expected to fail.
'bugs/*': [FAIL],
# Issue 3660: Replacing activated TurboFan frames by unoptimized code does
# not work, but we expect it to not crash.
'debug/debug-step-turbofan': [PASS, FAIL],
# Issue 3641: The new 'then' semantics suppress some exceptions.
# These tests may be changed or removed when 'chain' is deprecated.
'debug/es6/debug-promises/reject-with-throw-in-reject': [FAIL],
'debug/es6/debug-promises/reject-with-undefined-reject': [FAIL],
'debug/es6/debug-promises/reject-with-invalid-reject': [FAIL],
# Issue 5651: Context mismatch in ScopeIterator::Type() for eval default
# parameter value
'debug/es6/debug-scope-default-param-with-eval': [FAIL],
# Slow tests
'debug/debug-scopes': [PASS, SLOW],
'debug/debug-stepout-scope-part*': [PASS, SLOW],
'debug/ignition/debug-step-prefix-bytecodes': [PASS, SLOW, ['mode == debug', SKIP]],
# Too slow in debug mode and on slow platforms.
'regress/regress-2318': [PASS, SLOW, ['mode == debug or (arch != ia32 and arch != x64) or asan == True or msan == True', SKIP]],
[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
# forcing weak callback in asan build change break order
'debug/debug-stepin-builtin-callback': [['asan == True or msan == True', SKIP]],
}], # ALWAYS
##############################################################################
['variant == stress', {
# TODO(jarin/mstarzinger): Functions with eval or debugger now get optimized
# with Turbofan, which has issues with the debugger issues.
'debug/debug-evaluate-locals': [FAIL],
# Very slow in stress mode.
'regress/regress-2318': [SKIP],
}], # variant == stress
##############################################################################
['variant == stress_incremental_marking', {
# BUG(chromium:772010).
'debug/debug-*': [PASS, ['system == windows', SKIP]],
}], # variant == stress_incremental_marking
##############################################################################
['gc_stress == True', {
# Skip tests not suitable for GC stress.
# Tests taking too long
'debug/debug-stepout-scope-part1': [SKIP],
'debug/debug-stepout-scope-part2': [SKIP],
'debug/debug-stepout-scope-part3': [SKIP],
'debug/debug-stepout-scope-part4': [SKIP],
'debug/debug-stepout-scope-part5': [SKIP],
'debug/debug-stepout-scope-part6': [SKIP],
'debug/debug-stepout-scope-part7': [SKIP],
'debug/debug-stepout-scope-part8': [SKIP],
# Async function tests taking too long
# https://bugs.chromium.org/p/v8/issues/detail?id=5411
'debug/es8/async-debug-caught-exception-cases0': [SKIP],
'debug/es8/async-debug-caught-exception-cases1': [SKIP],
'debug/es8/async-debug-caught-exception-cases2': [SKIP],
'debug/es8/async-debug-caught-exception-cases3': [SKIP],
'debug/es8/async-function-debug-scopes': [SKIP],
}], # 'gc_stress == True'
##############################################################################
['variant == wasm_traps', {
'*': [SKIP],
}], # variant == wasm_traps
##############################################################################
['arch == arm and not simulator_run', {
# Too slow on chromebooks.
'debug/ignition/debug-step-prefix-bytecodes': [SKIP],
}], # 'arch == arm and not simulator_run'
##############################################################################
['arch == s390 or arch == s390x', {
# Stack manipulations in LiveEdit is not implemented for this arch.
'debug/debug-liveedit-check-stack': [SKIP],
'debug/debug-liveedit-double-call': [SKIP],
'debug/debug-liveedit-stack-padding': [SKIP],
'debug/debug-liveedit-restart-frame': [SKIP],
}], # 'arch == s390 or arch == s390x'
[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
]