dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Tests/LibJS/Bytecode/expected/eval-same-function.txt

19 lines
860 B
Text
Raw Normal View History

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:foo
[ 18] Call dst:reg5, callee:reg6, this_value:Undefined, foo
[ 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 "foo"
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] CreateArguments is_immutable:false
[ 18] GetCalleeAndThisFromEnvironment callee:reg6, this_value:reg7, identifier:eval
[ 30] CallDirectEval dst:reg5, callee:reg6, this_value:reg7, eval, arguments:[String("var x = 1")]
[ 58] GetBinding 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 "eval"
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] SetLexicalBinding identifier:x, src:Int32(1)
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
[ 20] End value:Undefined
Reference in a new issue Copy permalink