Interpreter: fix eval STRING strictures, glob assign, and open my $fh#229
Merged
Interpreter: fix eval STRING strictures, glob assign, and open my $fh#229
Conversation
1. Strict refs for ${block} scalar deref (BytecodeCompiler + CompileAssignment):
- Add DEREF_SCALAR_STRICT (335) and DEREF_SCALAR_NONSTRICT (336) opcodes
- BytecodeCompiler: emit DEREF_SCALAR_STRICT when strict refs enabled,
DEREF_SCALAR_NONSTRICT (with pkg) when disabled — matches JVM path in
EmitVariable.java case "$"
- CompileAssignment: same for ${block}=value and $$var=value assignment
- SlowOpcodeHandler: implement via scalarDeref()/scalarDerefNonStrict(pkg)
2. Strict vars for $identifier global access (BytecodeCompiler):
- Add shouldBlockGlobalUnderStrictVars() check in compileVariableReference()
for the global variable load path — was previously unchecked
3. Typeglob symbolic assignment *{"name"} = sub (CompileAssignment):
- Add LOAD_GLOB_DYNAMIC (334) opcode for runtime glob-by-name loading
- Handle BlockNode operand for * assignment, matching no-strict-refs symref
- Fixes op/require_gh20577.t glob assign in eval STRING
4. DEREF_GLOB (333) + LOAD_GLOB_DYNAMIC disassembler support (InterpretedCode)
Fixes comp/use.t: reduces interpreter-specific failures from -6 to -1 (test 23
is a pre-existing issue in both JVM and interpreter paths).
Fixes op/require_gh20577.t: glob assign works; @inc hook dispatch remains.
op/signatures.t baseline: 597/597.
IOOperator.open() calls fileHandle.set(glob) on the first argument, but RuntimeArray.push() copies the scalar via new RuntimeScalar(this), so the mutation was lost on the original lexical register. Fix in CompileOperator.java: after emitting OPEN, retrieve element 0 from the args array (which IOOperator.open() mutated) and SET_SCALAR it back into the fh lexical register. Fixes op/require_gh20577.t: now 7/9 (matching JVM baseline). Tests 6/7 remain pre-existing failures in both JVM and interpreter. op/signatures.t baseline: 597/597.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes interpreter feature gaps revealed under
JPERL_EVAL_USE_INTERPRETER=1.Test Results
op/signatures.top/require_gh20577.tcomp/use.tAll results now match the JVM baseline. Remaining failures are pre-existing in both modes.
Changes
Strict refs/vars for symbolic dereferences
New opcodes
DEREF_SCALAR_STRICT(335) andDEREF_SCALAR_NONSTRICT(336) mirror the JVM path (scalarDeref()/scalarDerefNonStrict(pkg)) for${block}and$$varreads and assignments. AddedshouldBlockGlobalUnderStrictVars()check incompileVariableReference()for bare$identifierglobal access underuse strict 'vars'. Fixescomp/use.ttests 21, 25–31.Symbolic typeglob assignment
New opcode
LOAD_GLOB_DYNAMIC(334) loads a glob by its runtime name, enabling*{"pkg::name"} = \&subinsideeval STRING. Required for FatPacked-style@INChooks that installINCmethods via glob assignment.open my $fhlexical filehandle propagationRuntimeArray.push()copies scalars vianew RuntimeScalar(this), soIOOperator.open()'s in-placefileHandle.set(glob)was mutating the copy, losing the filehandle in the original lexical register. Fix: after emittingOPEN, retrieveargs[0]from the array andSET_SCALARit back into the$fhregister. Fixesop/require_gh20577.ttests 4, 5, 8, 9.