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

40 lines
958 B
Text
Raw Normal View History

LibJS: Improve bytecode executable dump format Add a metadata header showing register count, block count, local variable names, and the constants table. Resolve jump targets to block labels (e.g. "block1") instead of raw hex addresses, and add visual separation between basic blocks. Make identifier and property key formatting more concise by using backtick quoting and showing base_identifier as a trailing parenthetical hint that joins the base and property names. Generate a stable name for each executable by hashing the source text it covers (stable across codegen changes). Named functions show as "foo$9beb91ec", anonymous ones as "$43362f3f". Also show the source filename, line, and column.
2026-03-18 19:56:54 -03:00
$e6445d4a eval-same-function.js:10:1
Registers: 7
Blocks: 1
Constants:
[0] = Undefined
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
LibJS: Improve bytecode executable dump format Add a metadata header showing register count, block count, local variable names, and the constants table. Resolve jump targets to block labels (e.g. "block1") instead of raw hex addresses, and add visual separation between basic blocks. Make identifier and property key formatting more concise by using backtick quoting and showing base_identifier as a trailing parenthetical hint that joins the base and property names. Generate a stable name for each executable by hashing the source text it covers (stable across codegen changes). Named functions show as "foo$9beb91ec", anonymous ones as "$43362f3f". Also show the source filename, line, and column.
2026-03-18 19:56:54 -03:00
block0:
LibJS: Drop dead entry GetLexicalEnvironment loads Teach the Rust bytecode generator to treat the synthetic entry GetLexicalEnvironment as a removable prologue load. We still model reg4 as the saved entry lexical environment during codegen, but assemble() now deletes that load when no emitted instruction refers to the saved environment register. This keeps the semantics of unwinding and environment restoration intact while letting empty functions and other simple bodies start at their first real instruction.
2026-04-13 08:16:17 -03:00
[ 0] GetGlobal dst:reg6, `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
LibJS: Improve bytecode executable dump format Add a metadata header showing register count, block count, local variable names, and the constants table. Resolve jump targets to block labels (e.g. "block1") instead of raw hex addresses, and add visual separation between basic blocks. Make identifier and property key formatting more concise by using backtick quoting and showing base_identifier as a trailing parenthetical hint that joins the base and property names. Generate a stable name for each executable by hashing the source text it covers (stable across codegen changes). Named functions show as "foo$9beb91ec", anonymous ones as "$43362f3f". Also show the source filename, line, and column.
2026-03-18 19:56:54 -03:00
foo$a4ff2c4f eval-same-function.js:6:9
Registers: 8
Blocks: 1
Constants:
[0] = String("var x = 1")
[1] = Undefined
[2] = Int32(42)
block0:
LibJS: Drop dead entry GetLexicalEnvironment loads Teach the Rust bytecode generator to treat the synthetic entry GetLexicalEnvironment as a removable prologue load. We still model reg4 as the saved entry lexical environment during codegen, but assemble() now deletes that load when no emitted instruction refers to the saved environment register. This keeps the semantics of unwinding and environment restoration intact while letting empty functions and other simple bodies start at their first real instruction.
2026-04-13 08:16:17 -03:00
[ 0] CreateArguments is_immutable:false
[ 10] GetCalleeAndThisFromEnvironment callee:reg6, this_value:reg7, `eval`
[ 28] CallDirectEval dst:reg5, callee:reg6, this_value:reg7, eval, arguments:[String("var x = 1")]
[ 50] GetBinding dst:reg6, `Number`
[ 68] CallConstruct dst:reg5, callee:reg6, Number, arguments:[Int32(42)]
[ 88] Return value:reg5
LibJS: Improve bytecode executable dump format Add a metadata header showing register count, block count, local variable names, and the constants table. Resolve jump targets to block labels (e.g. "block1") instead of raw hex addresses, and add visual separation between basic blocks. Make identifier and property key formatting more concise by using backtick quoting and showing base_identifier as a trailing parenthetical hint that joins the base and property names. Generate a stable name for each executable by hashing the source text it covers (stable across codegen changes). Named functions show as "foo$9beb91ec", anonymous ones as "$43362f3f". Also show the source filename, line, and column.
2026-03-18 19:56:54 -03:00
eval$3c61584c line 1, column 1
Registers: 5
Blocks: 1
Constants:
[0] = Int32(1)
[1] = Undefined
block0:
LibJS: Drop dead entry GetLexicalEnvironment loads Teach the Rust bytecode generator to treat the synthetic entry GetLexicalEnvironment as a removable prologue load. We still model reg4 as the saved entry lexical environment during codegen, but assemble() now deletes that load when no emitted instruction refers to the saved environment register. This keeps the semantics of unwinding and environment restoration intact while letting empty functions and other simple bodies start at their first real instruction.
2026-04-13 08:16:17 -03:00
[ 0] SetLexicalBinding `x`, src:Int32(1)
[ 18] End value:Undefined
Reference in a new issue Copy permalink