ScopeIterator skipped scopes that don't declare any variables (other
than the paused function's own scope). Now that ScopeIterator walks the
full lexical scope tree, keep empty scopes, so that the scope chain
reported via CDP (flagged with Debugger.Scope.emptyReason) matches the
lexical scopes, e.g. to match them against scopes in source maps and to
target them via `evaluateOnCallFrame` with `scopeNumber`.
Empty script scopes and empty eval root scopes (which also back wrapped
and Function() functions) are still skipped. [[Scopes]] is unaffected,
since the inspector omits empty scopes there itself.
R=pfaffe@chromium.org
Bug: 545412300
Change-Id: I0a5c0d71e66f7c4f747770c350713ff97dcc38ee
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8460466
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110382}
Now that DebugScriptScopeInfo provides the full lexical scope tree for
every script, ScopeIterator no longer switches to context-only
iteration when it leaves the paused closure. Instead it keeps walking
DebugScriptScope into outer lexical scopes, including outer scopes
that don't need a context. Stack-allocated variables of such scopes
are reported as unavailable. Iteration falls back to the context chain
once it leaves the root of the scope tree (e.g. for eval and wrapped
functions).
Empty outer scopes are still skipped for now; a follow-up changes that.
[[Scopes]] is unaffected, since the inspector builds it from the runtime
context chain.
- GetFunctionDebugName() returns undefined for outer scopes whose
enclosing function has no context, instead of using the name of an
unrelated closure context.
- DebugEvaluate uses the closest runtime context when targeting an
outer scope without a context (EvaluationContext()), and always wraps
it for contextless target scopes so the scope's blocklist applies,
even if the closest context is the native context. Otherwise
evaluating `x` in a contextless scope that declares `x` would find a
global `x`.
R=pfaffe@chromium.org
Bug: 545412300
Change-Id: Iaee6cfb7e1bee13c0bd6c3ff61d7e9c82a9b8491
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8460005
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110376}
As documented in src/ast/scopes.h, the block scope of a switch statement
("switch (tag) { cases }") should start at the opening "{" of the cases
block and end at "}".
Previously, ParseSwitchStatement set the switch block scope's
start_position to switch_pos (Token::kSwitch). Because the switch
discriminant `tag` is parsed and evaluated outside the cases block scope,
including `(tag)` in the switch block scope's source range caused
FindInnermostScope to falsely report the switch's BLOCK_SCOPE for source
positions inside the discriminant (e.g. a direct eval in `switch (eval(...))`).
Set the switch scope's start_position to `peek_position()` right before
consuming Token::kLeftBrace (matching ParseBlock) and update the DCHECK
in Parser::RewriteSwitchStatement accordingly.
Bug: 545412300
Change-Id: Ia6f5a5cc7df5607ace2b0aeb4d535edd4aaf67d7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8493632
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110222}
There are likely cleanups that can be done after this CL:
- context-related functions in the interpreter and compiler take ScopeInfo as
well as ScopeType and slot-count as input. The latter 2 should be directly
derived from the former. We should be able to drop FunctionContextParameters.
- ContextExtension is probably not needed anymore, since we now always have the
correct scope_info directly in the SCOPE_INFO_INDEX slot.
Bug: v8:7066
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ie1f6134c686a9f2183e54730d9cdd598a9e5ab67
Reviewed-on: https://chromium-review.googlesource.com/785151
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52952}
This is is a preparatory CL to detach the JSFunction from the Context.
We mainly rewrite the DebugScopeInterator to no longer rely on the a
JSFunction to be around. Additionally the empty_function needs to have
a proper ScopeInfo now.
Drive-by-fix: Improve ScopeInfo debug printing
Bug: v8:7066
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I2f2fa0e78914a12e076384e0e1234c2322ad1ee8
Reviewed-on: https://chromium-review.googlesource.com/918721
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52791}
let/const declarations in "standard" C-style for-loops have
some complex desugaring to accommodate the case where loop
loop variables may be captured. This slows down the baseline
performance of for-loops with let variables.
This change attempts to avoid this desugaring if it's known that
the loop variable is not captured at any point. A side effect of
this change is that let/const loop variables, when not captured
within the loop body, are not necessarily shown in the debugger,
similar to other stack-allocated vars.
BUG=v8:4762, v8:5460
R=marja@chromium.org, adamk@chromium.org, yangguo@chromium.org
Change-Id: I8dbe545a12c086f675972bdba60c94998268311a
Reviewed-on: https://chromium-review.googlesource.com/472247
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44731}
Simon Zünd
Ross McIlroy
Toon Verwaest
Camillo Bruni
Georg Neis
Caitlin Potter
yangguo