A CoverInitializedName such as `{ a = 0 }` (object shorthand with default) is
only valid when the enclosing object literal is refined into a destructuring
pattern. When such an object literal is instead consumed as a real value -- the
base of a member access, call, computed access, or tagged template, e.g.
`( {... { a = 0 }. b = 1 } )` -- the pending CoverInitializedName error was
discarded by a later assignment, so no SyntaxError was raised and the
AssignmentPattern property value reached bytecode generation, hitting
RELEASE_ASSERT_NOT_REACHED in Node::generateExpressionByteCode.
Report the pending CoverInitializedName as an early SyntaxError in the two
LeftHandSideExpression member-access loops the moment the base is consumed as a
value, since it can no longer be refined into a pattern.
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
BindingRestProperty in an object binding pattern only accepts a
BindingIdentifier, unlike BindingRestElement in an array binding pattern
which also accepts a BindingPattern. Throw a SyntaxError when `...` is
followed by `{` or `[` in a declaration context.
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
A `using` declaration in a switch case preceded by another statement
aborted with Assertion `isDisposableResourceRecord()' failed / SEGV in
finalizeDisposable.
The switch releases its discriminant register before generating the
case bodies, but pushLexicalBlock had allocated the disposable-record
register on top of it. The early giveUpRegister therefore freed the
disposable register instead, and a statement in the case body (e.g.
`o.k = 1`) reused that register slot, clobbering the record;
Initialize/FinalizeDisposable then dereferenced a non-pointer value.
When the switch block contains a `using` declaration, defer releasing
the discriminant temporaries until after finalizeLexicalBlock has
popped the disposable register (preserving LIFO order). Switches
without `using` are unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
`L: for (const v of [...]) { continue L; }` aborted with
Assertion `!v.isEmpty()' failed, and `continue OUTER` from a nested
loop silently terminated the script.
A `continue <label>` whose label targets a for-of loop was left to be
resolved by LabelledStatementNode after the loop body, by which point
the for-of iterator-cleanup try block had registered the jump as a
complex case. It was then morphed into a JumpComplexCase that unwound
the try block, wrongly closing the iterator and leaving an empty Value
in the result register.
A previous per-loop attempt (8fd141b2) was reverted (60b1202a) because
a single m_currentLoopLabel leaked into nested loops and broke test262.
Track all labels directly targeting a loop (m_currentLoopLabels), clear
the list when entering each loop body so nested loops never inherit it,
and let for-of/for-in resolve continues for its own labels to
continuePosition (a plain jump, identical to an unlabeled continue)
before the try block is registered as a complex case.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
A continue/break that is the first instruction inside a lexical block which
allocates an environment (e.g. `for(;c;){ continue; eval(); const x=1; }`) was
emitted as a plain Jump, skipping the block's CloseLexicalEnvironment. The
leaked environment then caused a subsequent outer-scope `const` to initialize
in the wrong environment, producing a spurious
`ReferenceError: Cannot access '...' before initialization`.
registerJumpPositionsToComplexCase compared jump positions against frontlimit
(= lexicalBlockStartPosition, the first body instruction) with strict `>`, so a
jump located exactly at the first body instruction was never morphed into a
JumpComplexCase and the block environment was left un-popped. Use `>=` for
break/continue/labelledBreak/labelledContinue.
With the environment now unwound correctly, the hasBinding guard band-aid in
InterpreterSlowPath::initializeByName is no longer needed and is removed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Remove the conditional labeled continue processing from loop statements.
The LabelledStatementNode correctly handles all labeled continues after the
labeled statement completes. Loops should only handle their own regular
(unlabeled) continues.
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Issue #1571: Labeled continue in do-while loops with allocated blocks
- Proper morphing for labeled continues crossing block boundaries
- Fixes environment record consistency in labeled loops
- Completes fix pattern across all loop statement types
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Issue #1571: Labeled continue in while loops with allocated blocks
- Proper morphing for labeled continues crossing block boundaries
- Fixes environment record consistency in labeled loops
- Applies fix pattern to all loop statement types
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Issue #1571 Crash #3: Labeled continue in for-of loop
- Iterator value issue when labeled continue triggered early
- Proper sequencing of iterator cleanup vs control flow
Issue #1571 Crash #4: With statement + labeled for-of
- Environment unwinding coordination with iterator cleanup
- CloseLexicalEnvironment called at correct time
Solution: Consume labeled continues with proper morphing
- Ensures iterator cleanup finalizer runs before unwinding
- Control flow record management stays consistent
- Both for-in and for-of (and for-await-of) properly handled
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Issue #1571 Crashes #3-4: Labeled continue in for loops
- Consume labeled continues targeting this loop with proper morphing
- Ensures iterator cleanup and environment unwinding work correctly
Issue #1571 Crashes #5-13: Environment record mismatch in labeled loops
- Proper morphing of labeled continues across allocated block boundaries
- Fixes crashes from scope-creating constructs in labeled loops
- Plain Jump path preserved for non-allocated blocks (zero overhead)
Solution: Call consumeLabelledContinuePositions with morphing enabled
- If no allocated block: plain Jump (fast path)
- If allocated block: JumpComplexCase with proper unwinding (correct path)
- Morphing is automatic via morphJumpPositionIntoComplexCase
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Signed-off-by: Seonghyun Kim <sh8281.kim@samsung.com>
Fix accidental deadlock possible inside the debugger and improve formatting when inspecting arrays.
Signed-off-by: Ádám László Kulcsár <adam.kulcsar@szteszoftver.hu>
skipSingleLine, skipSingleLineComment, and skipMultiLineComment incremented
the source index and then called peekCharWithoutEOF() without re-checking
eof(), causing a one-byte heap read past the source buffer when the input
ends with a bare \r or a trailing '*'. Guard each follow-up peek with eof().
Fixes#1568
Signed-off-by: SAY-5 <say.apm35@gmail.com>
Delete debugger_tester.sh script and rewrite it in python. Also add option to run individial tests.
Signed-off-by: Ádám László Kulcsár <adam.kulcsar@szteszoftver.hu>
