Found while verifying #915 (parent diagnostics lane #899). On exact parent 650efda, class C { static { eval("typeof new.target"); } } throws SyntaxError instead of yielding undefined. The prepared diagnostic patch changes the message but does not repair this existing runtime rejection. Reproduced through test262 --eval in tree and required-VM modes; actual system JSC accepts this direct-eval case.
Root-cause evidence: interpreter.zig static-block execution creates a variable environment and replaces this/home, but neither grants direct_eval_new_target_allowed nor installs an independent undefined new_target. The VM class-template path delegates to the same class evaluator. Ordinary function invocations already manage both fields.
Specification: ClassStaticBlockDefinitionEvaluation creates a non-lexical-this synthetic function; PerformEval recognizes its function environment. https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-classstaticblockdefinitionevaluation and https://tc39.es/ecma262/multipage/global-object.html#sec-performeval
Acceptance: direct/nested direct eval and arrows inherit the static block binding; indirect eval still rejects; an enclosing constructor new.target never leaks into the block; caller state is restored after normal and abrupt completion; test tree and required VM, including GC-safe rooting of the saved caller value. Audit the adjacent field-initializer boundary for the same defect without silently widening this fix. Re-run focused class/eval corpus and preserve memory guards. Do not emulate the separate JSC PrivateSymbol.newTargetLocal error observed for a tagged-template static-block case.
Evidence: /private/tmp/zig-js-new-target-oracle.ZOJlB1. No fix landed yet.
Found while verifying #915 (parent diagnostics lane #899). On exact parent 650efda, class C { static { eval("typeof new.target"); } } throws SyntaxError instead of yielding undefined. The prepared diagnostic patch changes the message but does not repair this existing runtime rejection. Reproduced through test262 --eval in tree and required-VM modes; actual system JSC accepts this direct-eval case.
Root-cause evidence: interpreter.zig static-block execution creates a variable environment and replaces this/home, but neither grants direct_eval_new_target_allowed nor installs an independent undefined new_target. The VM class-template path delegates to the same class evaluator. Ordinary function invocations already manage both fields.
Specification: ClassStaticBlockDefinitionEvaluation creates a non-lexical-this synthetic function; PerformEval recognizes its function environment. https://tc39.es/ecma262/multipage/ecmascript-language-functions-and-classes.html#sec-runtime-semantics-classstaticblockdefinitionevaluation and https://tc39.es/ecma262/multipage/global-object.html#sec-performeval
Acceptance: direct/nested direct eval and arrows inherit the static block binding; indirect eval still rejects; an enclosing constructor new.target never leaks into the block; caller state is restored after normal and abrupt completion; test tree and required VM, including GC-safe rooting of the saved caller value. Audit the adjacent field-initializer boundary for the same defect without silently widening this fix. Re-run focused class/eval corpus and preserve memory guards. Do not emulate the separate JSC PrivateSymbol.newTargetLocal error observed for a tagged-template static-block case.
Evidence: /private/tmp/zig-js-new-target-oracle.ZOJlB1. No fix landed yet.