Fix interpreter strict vars check to allow use-vars-declared globals#270
Merged
Conversation
The BytecodeCompiler shouldBlockGlobalUnderStrictVars() was missing the allowIfAlreadyExists check that the JVM backend (EmitVariable.java) has. When a large file like ExifTool.pm (10K lines) falls back from JVM to interpreter compilation, CompilerFlagNode in the AST re-enables strict vars. But use vars declarations (which create globals at parse time) were not recognized by the interpreter strict check, causing false 'requires explicit package name' errors. The fix checks GlobalVariable.existsGlobalVariable/Array/Hash() before blocking access, mirroring the JVM backend logic. Impact: ExifTool tests go from 0/600 (all crashing) to 597/600 (99.5%). Generated with [Devin](https://cli.devin.ai/docs) Co-Authored-By: Devin <noreply@cognition.ai>
RuntimeScalar.set(null) could occur in large interpreter-compiled subroutines (e.g., WriteExif.pl) when a register holds a null value from a nested call chain. Treat null as undef, matching Perl semantics. This fixes the remaining 3 ExifTool test crashes (DNG test 3, Nikon tests 8-9), bringing ExifTool from 597/600 to 600/600 (100%). Generated with [Devin](https://cli.devin.ai/docs) Co-Authored-By: Devin <noreply@cognition.ai>
Null elements can enter RuntimeArray via delete(), sparse initialization, or array extension. These nulls propagate through addToArray() and setFromList() into RuntimeList, where scalar() or set() on them causes NPEs. Add null guards in RuntimeList.scalar() and setFromList() to treat null elements as undef, matching Perl semantics. Generated with [Devin](https://cli.devin.ai/docs) Co-Authored-By: Devin <noreply@cognition.ai>
…captures, error message - Add single-letter variable restriction to interpreter shouldBlockGlobalUnderStrictVars, mirroring EmitVariable.java: single Unicode letter vars cannot bypass strict just because they exist in GlobalVariable registry. Fixes uni/variables.t (115 failures to 0). - Reject leading-zero capture variables ($01, $02) under strict in both BytecodeCompiler and EmitVariable. Fixes 12 re/pat.t failures (253 to 241). - Fix open() error message to match Perl: Unknown open() mode. Fixes io/open.t (33 to 31). Generated with [Devin](https://cli.devin.ai/docs) Co-Authored-By: Devin <noreply@cognition.ai>
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
shouldBlockGlobalUnderStrictVars()was missing theallowIfAlreadyExistscheck that the JVM backend (EmitVariable.java) hasCompilerFlagNodein the AST re-enables strict varsuse varsdeclarations (which create globals at parse time) were not recognized by the interpreter's strict check, causing falserequires explicit package nameerrorsGlobalVariable.existsGlobalVariable/Array/Hash()before blocking access, mirroring the JVM backend logicImpact
Remaining 3 ExifTool failures
DNG test 3 and Nikon tests 8-9 crash with a null register NPE in WriteExif.pl's interpreter-compiled bytecode (
Cannot read field "type" because "value" is nullat MY_SCALAR opcode). These are EXIF write operations in a very large subroutine — a pre-existing interpreter register management issue, not related to this change.Test plan
mvn test— 156/156 passmake test-interpreter— 156/156, 7078/7078 passGenerated with Devin