ladybird/Tests/LibJS/Bytecode/expected/eval-scope-optimization.txt

JS bytecode executable ""
[   0]    0: GetLexicalEnvironment dst:reg4
[   8]       GetGlobal dst:reg6, identifier:outer
[  18]       Call dst:reg5, callee:reg6, this_value:Undefined, outer
[  38]       End value:reg5

JS bytecode executable "outer"
[   0]    0: GetLexicalEnvironment dst:reg4
[   8]       CreateVariable identifier:inner, is_immutable:false, is_global:false, is_strict:false
[  18]       InitializeVariableBinding identifier:inner, src:Undefined
[  30]       NewFunction dst:reg5
[  48]       SetVariableBinding identifier:inner, src:reg5
[  60]       GetGlobal dst:reg6, identifier:Number
[  70]       CallConstruct dst:reg5, callee:reg6, Number, arguments:[Int32(42)]
[  90]       Return value:reg5
LibJS: Stop propagating is_inside_scope_with_eval across functions Previously, when a nested function contained eval(), the parser would mark all identifiers in parent functions as "inside scope with eval". This prevented those identifiers from being marked as global, forcing them to use GetBinding instead of GetGlobal. However, eval() can only inject variables into its containing function's scope, not into parent function scopes. So a parent function's reference to a global like `Number` should still be able to use GetGlobal even if a nested function contains eval(). This change adds a new flag `m_eval_in_current_function` that propagates through block scopes within the same function but stops at function boundaries. This flag is used for marking identifiers, while the existing `m_screwed_by_eval_in_scope_chain` continues to propagate across functions for local variable deoptimization (since eval can access closure variables). Before: `new Number(42)` in outer() with eval in inner() -> GetBinding After: `new Number(42)` in outer() with eval in inner() -> GetGlobal 2026-01-26 17:17:28 -03:00			`JS bytecode executable ""`
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment 2026-02-08 23:34:42 -03:00			`[ 0] 0: GetLexicalEnvironment dst:reg4`
			`[ 8] GetGlobal dst:reg6, identifier:outer`
			`[ 18] Call dst:reg5, callee:reg6, this_value:Undefined, outer`
			`[ 38] End value:reg5`
LibJS: Stop propagating is_inside_scope_with_eval across functions Previously, when a nested function contained eval(), the parser would mark all identifiers in parent functions as "inside scope with eval". This prevented those identifiers from being marked as global, forcing them to use GetBinding instead of GetGlobal. However, eval() can only inject variables into its containing function's scope, not into parent function scopes. So a parent function's reference to a global like `Number` should still be able to use GetGlobal even if a nested function contains eval(). This change adds a new flag `m_eval_in_current_function` that propagates through block scopes within the same function but stops at function boundaries. This flag is used for marking identifiers, while the existing `m_screwed_by_eval_in_scope_chain` continues to propagate across functions for local variable deoptimization (since eval can access closure variables). Before: `new Number(42)` in outer() with eval in inner() -> GetBinding After: `new Number(42)` in outer() with eval in inner() -> GetGlobal 2026-01-26 17:17:28 -03:00
			`JS bytecode executable "outer"`
LibJS: Replace implicit environment stack with explicit registers Replace the saved_lexical_environments stack in ExecutionContextRareData with explicit register-based environment tracking. Environments are now stored in registers and restored via SetLexicalEnvironment, making the environment flow visible in bytecode. Key changes: - Add GetLexicalEnvironment and SetLexicalEnvironment opcodes - CreateLexicalEnvironment takes explicit parent and dst operands - EnterObjectEnvironment stores new environment in a dst register - NewClass takes an explicit class_environment operand - Remove LeaveLexicalEnvironment opcode (instead: SetLexicalEnvironment) - Remove saved_lexical_environments from ExecutionContextRareData - Use a reserved register for the saved lexical environment to avoid dominance issues with lazily-emitted GetLexicalEnvironment 2026-02-08 23:34:42 -03:00			`[ 0] 0: GetLexicalEnvironment dst:reg4`
			`[ 8] CreateVariable identifier:inner, is_immutable:false, is_global:false, is_strict:false`
			`[ 18] InitializeVariableBinding identifier:inner, src:Undefined`
			`[ 30] NewFunction dst:reg5`
			`[ 48] SetVariableBinding identifier:inner, src:reg5`
			`[ 60] GetGlobal dst:reg6, identifier:Number`
			`[ 70] CallConstruct dst:reg5, callee:reg6, Number, arguments:[Int32(42)]`
Tests: Rebaseline bytecode tests after handler/finalizer collapse The exception handler dump format changed from showing both handler and finalizer offsets to showing only a single handler offset. 2026-02-09 08:16:05 -03:00			`[ 90] Return value:reg5`