When parsing the parameter list of an arrow function that is nested
inside an outer arrow function, the inner arrow function's
DeclarationScope does not exist yet, so `scope()->GetClosureScope()`
returns the outer arrow function's scope (`closure_scope !=
receiver_scope`).
Previously, `ParserBase::UseThis()` only called
`expression_scope()->RecordThisUse()` when `closure_scope ==
receiver_scope`. As a result, referencing `this` in a default parameter
of a nested arrow function failed to mark the inner
`ArrowHeadParsingScope` as using `this`, leaving `has_this_reference()`
false on the inner arrow function's `DeclarationScope` and causing
debug-evaluate to resolve `this` to `undefined`.
Call `expression_scope()->RecordThisUse()` unconditionally in
`UseThis()` so that any enclosing `ArrowHeadParsingScope` records the
`this` reference.
TAG=agy
CONV=905f9f91-322f-467a-9f81-1f78a365b0d8
Change-Id: Ia4ab7176549719d1c8e73351cafb92069f883d03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8553279
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110816}
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}
Update DebugEvaluate::ContextBuilder to populate and look up locals
block-lists via EnsureLocalsBlockList and CalculateScopeBlockList
instead of relying on ScopeIterator's CalculateBlocklists::kIfNeeded.
When evaluating in an outer scope without its own runtime Context,
calculate its [S_eval, K) block-list on the fly and attach it to the
synthetic DebugEvaluateContext ScopeInfo with an empty wrapped_context.
R=pfaffe@chromium.org
Bug: 545412300
Change-Id: I962c95f797c2d73730278fc3a017763794b5b0ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8437698
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#110022}
ScopeInfo::ModuleIndex() scanned the module_variables entries linearly,
comparing the requested name against every module variable's name. It is
called from Scope::LookupInScopeInfo for every free variable of every
lazily compiled function inside a module, so its cost scales with
(#module variables) x (#free variable references) per compile. Bundled
ES-module chunks routinely declare 800-900 module variables (imports plus
exports); on a large web app ModuleIndex was ~2% of the renderer main
thread during page load, all of it under Runtime_CompileLazy.
Give module scopes with at least kScopeInfoMaxInlinedLocalNamesSize module
variables a NameToIndexHashTable mapping each module variable's name to its
entry in module_variables (mirroring context_local_names_hashtable), fill
it in ScopeInfo::Create, and use it in ModuleIndex. The new tail slot sits
after module_variables and before dependent_code; its presence depends only
on the scope type and module_variable_count, both of which precede the
object slots, so partially initialized objects still size correctly.
Measured on a production React app served as 115 ES-module chunks: time
under ScopeInfo::ModuleIndex on the main thread dropped from 23 ms to 1 ms
per page load, Scope::LookupInScopeInfo from 26 ms to 5 ms.
Bug: none
Change-Id: I211704c5a713ec9df89d87ec40a0cafb282d5bd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8259941
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Olivier Flückiger <olivf@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109583}
This CL marks `Debugger.setScriptSource` as deprecated in
js_protocol.pdl, makes the method return an unconditional "no longer
available" error, and deletes all inspector and debugger tests that
tested live editing.
TAG=agy CONV=ed8ed8e4-6d14-4137-9725-7cc8e7f930ef
Bug: 434596678
Change-Id: I80ff93d558aee861916b1743ba37e6ac91ae54c3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8238091
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109162}
Fixes a logical defect where stack-allocated variables from inner scopes
that do not require a context incorrectly polluted the blocklist of an
outer physical context. When `has_matched_first_context_` is false and
we encounter the first context-requiring scope, `context_blocklist_` is
now properly cleared. This prevents variables from contextless inner
scopes from leaking into the physical context's blocklist and causing
spurious ReferenceErrors when evaluating in the debugger.
Bug: 542461144
Change-Id: Ie58a75bda57be1bfa0745aada25b9b818d8256a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8198947
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109093}
In `v8::Isolate::RequestInterrupt` the API contract says:
API interrupt callbacks are forbidden from executing JavaScript
on the interrupted Isolate.
This CL prepares the infrastructure to enforce this contract.
Bug: 540137721, 40067940
TAG=agy
CONV=78573798-a951-4bd3-9c6f-3e3b6775da4b
Change-Id: I43cc83c3cc3ebd34052a927dde55bbf4d49d2d29
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8173727
Auto-Submit: Olivier Flückiger <olivf@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Olivier Flückiger <olivf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109086}
A recent change added support to evaluate expressions outside the paused function.
Because of this change, Context::Lookup must now check blocklists when it inspects outer closure scopes.
Before this change, Debugger.evaluateOnCallFrame did not check blocklists for outer closure scopes.
Lookups for stack-allocated variables in an outer closure scope did not throw a ReferenceError.
This occurred for two reasons:
1. ContextBuilder did not wrap outer closure evaluation contexts in a DebugEvaluateContext to trigger the blocklist check in Context::Lookup.
2. LocalBlocklistsCollector did not store the blocklist for the outermost closure context in the cache.
This change fixes both issues:
- ContextBuilder now wraps outer closure evaluation contexts in a DebugEvaluateContext.
- LocalBlocklistsCollector now collects locals for outer closure scopes and caches the blocklist for the outermost closure context.
Test coverage is added to debugger/debug/debug-evaluate-shadowed-context and debugger/debug/debug-evaluate-shadowed-context-reuse.
TAG=agy
CONV=068e94d1-a67a-4e1b-99dc-4d6cc055acdd
R=pfaffe@chromium.org
Bug: 542461144
Change-Id: If2f070aa0dc2aa7f201a34105a31639aeba96e1e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8202625
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109072}
This change adds an optional 'scopeNumber' parameter to the
'Debugger.evaluateOnCallFrame' CDP command.
The 'scopeNumber' parameter specifies the 0-based index of the scope
to evaluate in. The index matches the scope chain from the
'Debugger.paused' event. If you do not provide a 'scopeNumber',
the default value is 0 (the innermost scope).
Key changes:
- CDP Protocol: Add optional integer 'scopeNumber' to the
'Debugger.evaluateOnCallFrame' command in js_protocol.pdl.
- Inspector: Validate 'scopeNumber' in 'V8DebuggerAgentImpl'.
If 'scopeNumber' is not valid, the command returns an error:
"Could not find scope with given number".
- Debug Evaluate: Update 'ContextBuilder' to start evaluation from
the specified scope.
- For an inner scope, the builder excludes block scopes that are
deeper than 'scopeNumber'.
- For an outer scope (closure, script, or global), the builder
evaluates in the context of that scope. Variables in inner
scopes are not visible.
- Tests: Add '.evaluate(expression)' to 'Scope' objects in
test-api.js. Add tests in test/inspector/debugger/ and
test/debugger/debug/ to verify evaluation across different scopes.
TAG=agy
CONV=881baa05-e1f7-4dbe-a278-ce57441c77bc
Fixed: 542461144
Change-Id: Ida16237e8418bfc5422f48cad3e6a4052b3b282d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8200344
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Philip Pfaffe <pfaffe@chromium.org>
Reviewed-by: Eric Leese <leese@chromium.org>
Cr-Commit-Position: refs/heads/main@{#109062}
When the debugger pauses, it can execute arbitrary JS (e.g. via
evaluation or inspector listeners). This JS can modify heap state,
such as detaching ArrayBuffers.
If the execution stack contains optimized frames, they might be using
load-eliminated values (like backing store pointers or array lengths)
that are now invalidated by the heap modifications.
To prevent use-after-free or out-of-bounds accesses when resuming,
deoptimize the topmost optimized JS frame when handling a debug break.
We only need to deoptimize the topmost frame because any caller frames
are at a call site, which acts as a memory serialization barrier,
forcing them to reload all heap state upon return anyway.
TAG=agy
CONV=be1ec857-0c4b-479c-ba1b-e84d8741da83
Bug: 531297707
Change-Id: I5e46963660eaa228a68422490e7495ec6f0d9f8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8131283
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#108890}
Remove all asm.js-related test cases, files, and their status file
entries, as part of decommissioning the legacy asm.js support in V8.
This cleans up:
1. test/mjsunit/asm/ and test/mjsunit/regress/asm/ directories.
2. All asm.js tests in debugger, inspector, message, and unittest suites.
3. Obsolete entries from mjsunit.status, message.status, and
inspector.status.
TAG=agy
R=jkummerow@chromium.org
Bug: 510487707
Change-Id: Iff52354ec8cb0015471af35aee28bddd9fa834a9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8128084
Commit-Queue: Clemens Backes <clemensb@chromium.org>
SLSA-Policy-Verified: SLSA Policy Verification Service <devtools-gerritcodereview-exitgate@google.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#108787}
When a function .prototype is accessed for the first time during
side-effect-free evaluation (Runtime.evaluate), GetFunctionPrototype
lazily allocates the .prototype object (JSObject) and its initial Map.
Previously, GetFunctionPrototype disabled temporary object tracking
(DisableTemporaryObjectTracking) around this allocation so that
mutations to the prototype of a permanent function would not be
misidentified as temporary. However, when tracking was disabled,
AllocationEvent simply returned without taking any action. If the newly
allocated prototype object or its Map reused memory addresses belonging
to dead temporary objects, those stale memory ranges remained in
TemporaryObjectsTracker::regions_. Consequently, HasObject incorrectly
identified the permanent function prototype as a temporary object,
allowing its prototype to be polluted during debug evaluation without
triggering a side-effect check error.
To fix this simply and robustly:
1. When TemporaryObjectsTracker::AllocationEvent is invoked while
tracking is disabled (disabled == true), it explicitly calls
RemoveFromRegions(addr, addr + size). This clears out any stale
overlapping memory ranges from dead temporary objects while
ensuring the new allocation is not added to regions_.
2. JSFunction::GetFunctionPrototype conditionally enters
DisableTemporaryObjectTracking when the parent JSFunction (function)
is not a temporary object (!isolate->debug()->IsTemporaryObject(function)).
TAG=agy
CONV=b7469c8c-dfea-4bf5-ae4e-e442ac035cad
Bug: 532099983
Change-Id: I9586b1db45a768dc1f3f7cde10c4a7f72fe1b661
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8064726
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#108584}
Out of scope in this first prototype:
- OSR
- Resumable loops
- Loop headers with != 2 predecessors
- Loops with exception handlers
- Throwable nodes inside the loop
- Allocations inside the loop
- Switchs inside the loop
- Terminal control inside the loop (return/deopt/...)
- Exit block with phi nodes
- Distinct exit blocks (labelled continue/breaks)
- Any non-header phi used by blocks that the loop dominates
Bug: 517439598
Change-Id: Ic02ec02d4dd85aab0fe396b8acfe676208b38905
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7880751
Reviewed-by: Darius Mercadier <dmercadier@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#107891}
Currently, when we want to make sure that a function is not present in
any optimized code (whether as the top-level function or an inlined
function), we can deopt existing optimized code but have to abort all
ongoing compilation jobs since we don't have visibility into what they
have or will inline.
This has the problem that, if you are breakpointing or stepping a lot,
you can starve a function that is trying to optimize despite being
unrelated to the function you are trying to debug -- it will repeatedly
try to optimize and get aborted. This is unlikely to show up much in
real-world cases (though it could, particularly with automated
debugging), but it certainly shows up in debugget unit tests in
compilation stress variants.
Rather than aborting compilation jobs, we can let them finish, and then
potentially immediately deopt if we got unlucky. This means blocking the
main thread, but since this is the debugger, that's probably ok.
Change-Id: Ib195150df93b7feab758b4bd6fad0a6c6494c0d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7766696
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#106551}
We have three failure classes:
1. Side effects test: the debugger side effects test automatically tests
all Date properties for side effects. It understandably fails on the
builtin Date.toTemporalInstant since it can't be run in pure
bytecode.
2. format-range tests: There is a specific order of operations where
Intl.DateTimeFormat must run ToNumber first. Temporal patches the
Intl spec and the patch was not implemented 100% correctly.
3. comma-compat-on: We have a special flag to restore older ICU4C
behavior, which was only in the pre-Temporal code.
Bug: 401065166
Change-Id: Ie1ced463a2e5710b2664efefbd61d5a06a6a6964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7111926
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Manish Goregaokar <manishearth@google.com>
Cr-Commit-Position: refs/heads/main@{#103504}
We plan to deprecate and remove the live edit functionality. This CL
puts the feature behind a flag that'll cause Debugger.setScriptSource
to fail with a ServerError in case the flag is disabled.
The CL also updates all affected tests to specifically enable the
feature.
Drive-by: Make the runtime function go through Debug::SetScriptSource
so also the tests in test/debugger honor the flag.
R=bmeurer@chromium.org
Bug: 434574729
Change-Id: Idd8b57ef67258c4946e66028b3df8427ce89b8da
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6929582
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#102348}
"quit()" is omitted by --omit-quit on fuzzers, but testRunner.quit()
is not. This removes the latter and replaces it with the former
again, as the reason for its existence is probably no longer valid.
This also cleans up spurious flag definitions of --omit-quit that
were probably just copy/pasted.
Bug: 419439367
Change-Id: I6923487850bd0e29450a5ecccb4085c01ca8a58d
Cq-Include-Trybots: luci.v8.try:v8_linux_arm_lite_rel
Cq-Include-Trybots: luci.v8.try:v8_linux64_predictable_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6578863
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#100511}
This CL changes the stepping behavior for the following 'for' loops:
for (const each of subject) {
for (const each in subject) {
for await (const each of subject) {
Currently we stop before the iterator 'next()' call (or before the
'done' check in the 'in' case). This leads to unintuitive stepping
behavior: For a loop with N iterations, we'll pause N + 1 times on
the 'const each' declaration.
This CL changes the iterator 'next()' call to a unbreakable source
position (to preserve stack traces) and makes the assignment to
the 'each' variable a breakable position instead.
This way, if a loop iterates N times, we'll pause N times on the
'const each' declaration.
R=bmeurer@chromium.org, leszeks@chromium.org
Fixed: 407773675
Change-Id: Id013447a1edeb39bbbffffab71922405e220afed
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6508377
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#100058}
This CL adds some tests for break locations/stepping for 'for await'
loops in anticipation of changing the stepping behavior in a follow up.
Drive-by: For the 'debug-stepnext-for.js' suite of tests, we also print
a marker for the paused position when running the test.
R=bmeurer@chromium.org
Bug: 407773675
Change-Id: I1535e751e6a3fa0981600ebfb41ab22936e99bc6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6508376
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#100052}
This is a reland of commit d2ab66c2a9
Changes from original:
- The test inspector/debugger/set-breakpoint-after-gc relies on
precise garbage collection and may fail if conservative stack
scanning is used. We call GC multiple times to ensure the weak
reference hold by the script is eventually collected.
- Allow reading a ContextCell when printing debug stack frame.
Original change's description:
> [contexts] Unify context accessors after ContextCells
>
> The introduction of ContextCells removed the need for special handling
> for ScriptContext (which previously used a side table for
> let/const tracking and mutable numbers).
>
> This change refactors the context access logic:
> - Internal get/set accessors are now protected to the Context class.
> - External access should use the new functions:
> - Get/Set: A safe (though potentially slower)
> function for accessing elements in any context.
> - GetNoCell/SetNoCell: A faster function that verifies the
> element being accessed is not a ContextCell.
>
> Additionally, related bytecode operations and optimizer functions have
> been renamed for consistency with these changes.
>
> Bug: 408128754
>
> Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#99844}
Bug: 408128754, 40789559
Change-Id: I78a3a99a4f364ed78965fbed56a084d38382d2fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6479814
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#99865}
This reverts commit d2ab66c2a9.
Reason for revert: Breaking CSS
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20css%20-%20debug/12484/overview
Original change's description:
> [contexts] Unify context accessors after ContextCells
>
> The introduction of ContextCells removed the need for special handling
> for ScriptContext (which previously used a side table for
> let/const tracking and mutable numbers).
>
> This change refactors the context access logic:
> - Internal get/set accessors are now protected to the Context class.
> - External access should use the new functions:
> - Get/Set: A safe (though potentially slower)
> function for accessing elements in any context.
> - GetNoCell/SetNoCell: A faster function that verifies the
> element being accessed is not a ContextCell.
>
> Additionally, related bytecode operations and optimizer functions have
> been renamed for consistency with these changes.
>
> Bug: 408128754
>
> Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#99844}
Bug: 408128754
Change-Id: I8bcbe024f563e8e2af88ec439ebfe5777e43b158
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6478800
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#99846}
The introduction of ContextCells removed the need for special handling
for ScriptContext (which previously used a side table for
let/const tracking and mutable numbers).
This change refactors the context access logic:
- Internal get/set accessors are now protected to the Context class.
- External access should use the new functions:
- Get/Set: A safe (though potentially slower)
function for accessing elements in any context.
- GetNoCell/SetNoCell: A faster function that verifies the
element being accessed is not a ContextCell.
Additionally, related bytecode operations and optimizer functions have
been renamed for consistency with these changes.
Bug: 408128754
Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#99844}
- Remove the `--expose-wasm` flag and instead determine based on the
other flags (`--jitless`, `correctness-fuzzer-suppressions`,
`--wasm-jitless`) whether the WebAssembly object should be installed
as a global property.
- Always use the WebAssembly object from the context for installing new
(conditional) features.
- Add more checks when installing new properties.
- Make some methods private.
Bug: 373485797
Change-Id: I1b39502a6b6a1b680a3d481b2c6c0031431c9c45
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5932661
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#96636}
... because debugger interrupts can allocate and GC interrupts can be
processed during JS loop stack checks. Without the .CanAllocate()
effect, we could do allocation-folding around loop stack checks, which
is broken when a GC happens during the stack check.
Bug: chromium:42202729, chromium:42204525
Change-Id: I5d313e077b04582123dd5ca3fd99142a13ca2ac2
Fixed: chromium:354005322
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5736202
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Reviewed-by: Matthias Liedtke <mliedtke@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#95236}
Some methods were not allowlisted because in the past, they were
implemented as JS builtins and there were side-effects due to creating
an i18n cache object.
Some other methods were not allowlisted because they run regexps, which
can affect RegExp.$1 etc – that has since then been worked around.
For String.{match, matchAll, replace, replaceAll, split, search} we
invalidate the protector cell to avoid the fast path that inlines calls
to RegExp.prototype[Symbol.*].
Bug: 351769842
Change-Id: I2e5276b81d5b48488fc716d183a7ffa74a225604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5720968
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#95118}
This changes the source positions for static elements and instance
members initializer functions to only cover exactly the region of a
class they need. ParseClassLiteralBody is changed to only parse body
statements, not everything starting from { to }. And class literal
rewriting is moved outside to where the class literal is parsed, so
that initializer functions can only do the bits that they need.
The entire outer scope chain is always deserialized, and is used as
the scope for parsing. Private variables and variables for computed
field names are allowed to be created on the scope despite already
being resolved. FinalizeReparsedClassScope is repurposed to properly
initialize those variables after we finished parsing the class body.
Change-Id: I87d10bc633dee40b99437af87d600fe06d711afc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5676330
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94853}
mutex
There's a lock-order inversion between the `allocation_mutex_` used by
`NativeModule::EstimateCurrentMemoryConsumption` and the `mutex_` which
is used by `DebugInfo::SetBreakpoint`.
This CL: we only get the `DebugInfo` pointer while holding the
`allocation_mutex_`, and access it after the mutex was released.
Change-Id: Id0207fd34af031caebc0c432444056de6e823baf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5668523
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Eva Herencsárová <evih@chromium.org>
Cr-Commit-Position: refs/heads/main@{#94734}
In JavaScript, a breakpoint with a false condition will prevent
stopping for other reasons (usually exceptions) on the same
statement. This is the basis of the DevTools "Never Pause Here"
feature. This change brings the same behavior to WebAssembly,
so that this can be used to ignore Wasm traps.
Bug: b:341040531
Change-Id: I9f9b5d4632c8261dcbd50130bb8882728ac76474
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5544146
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eric Leese <leese@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93966}
and dispose method
This CL adds DisposableStack constructor, use() and dispose() methods
as developer exposed methods. Also, this CL fixed the use
of `using` keyword with `null` and `undefined` and adds tests for them.
Bug: 42203506
Change-Id: If50b9e33d9cbb3de2be41dc81e656d9d202b8fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5498999
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93807}
We introduce a new JSLoopStackCheckOp operation in Turboshaft for
this rather than using the existing StackCheckOp, because JS loop
stack checks are significantly different from other stack checks:
- They have fewer effects (no write can happen during the interrupt)
- They have additional inputs (frame state and context)
- Their lowering is different (it doesn't check the current stack
pointer, but just a field on the isolate).
StackCheckOp was slightly refactored to make it clearer that it
does not handle JS loop stack checks.
Bug: v8:12783, v8:14581
Change-Id: I2820c4d015b218cc9665e792bda2352c99f5ee72
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5441116
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Darius Mercadier <dmercadier@chromium.org>
Auto-Submit: Darius Mercadier <dmercadier@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93344}
When doing catch prediction on a rejected promise assumed to be
propagating up the call stack, we check on each js frame if the
returned value is then used for chained promise methods like
.then, .finally, and .catch, and if any call in the chain is
.catch or a two-argument .then, we assume the rejection will be
caught.
Also overhauls how we scan through inlined frames and adds
tests for catch prediction in inlined call stacks.
Bug: b:40283993
Change-Id: I3b327c6823b2da3d160a237aefba3bdac96ae808
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5388436
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Eric Leese <leese@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93227}
Toon Verwaest