String eval does not inherit strict vars on either backend

Start with EvalStringHandler.java around lines 317-322 and 500-510, then inspect RuntimeCode.evalStringWithInterpreter and the shared eval-context capture. Run the minimal strict-vars reproducer and the Exporter::Easy 0.18 suite on both backends. Done means strict vars is inherited, no strict vars still disables it, declared variables remain usable, and permanent regression coverage passes.

Summary

PerlOnJava does not inherit use strict's vars setting into string eval compilation. As a result, undeclared package variables inside an eval string execute successfully instead of producing Perl's compile-time strict-vars error.

This causes Exporter::Easy 0.18's negative tests to fail on both PerlOnJava backends.

CPAN failure

Archived CPAN run: 20260918-141920-96054

Distribution: Exporter-Easy-0.18

Target: Exporter::Easy

Results:

t/Easiest.t .. ok
t/Easy.t ..... 4 failed of 51
Files=2, Tests=72

The four failures are:

list vars can't use var @goodbye
list vars can't use var %goodbye
no vars can't use var @goodbye
no vars can't use var %goodbye

The test helper evaluates each expression with:

eval "package $pkg;$code"

Under system Perl, the undeclared @goodbye and %goodbye references correctly die under the surrounding use strict. Under PerlOnJava they execute successfully, so the negative assertions fail.

Minimal reproducer

use strict;

my $result = eval q{@goodbye};
die "strict vars was not enforced" unless $@;

Expected result: the eval fails with a diagnostic equivalent to:

Global symbol "@goodbye" requires explicit package name

Observed on both JVM and interpreter backends: the eval succeeds and returns an empty array value.

The CPAN test's package-qualified form also reproduces the issue:

use strict;
my $package = __PACKAGE__;
my $ok = eval "package $package;\\@goodbye";

Oracle comparison

The unchanged upstream suite passes completely under system Perl 5.42.2:

t/Easiest.t .. ok
t/Easy.t ..... ok
All tests successful.
Files=2, Tests=72

There are no XS/native components or external services involved.

Investigation and suspected ownership

The failure is in string-eval lexical-state propagation, not in Exporter::Easy's export logic.

The JVM eval path is implemented by EvalStringHandler. It creates a fresh ScopedSymbolTable and is intended to inherit strict options from the caller around EvalStringHandler.java lines 317-322 and 500-510. The eval parser then performs strict-vars validation against that new table.

The interpreter eval path is implemented by RuntimeCode.evalStringWithInterpreter; it obtains the saved eval context and parses the string separately. It exhibits the same missing strict-vars behavior, so the shared eval-context capture/propagation or eval compilation setup should be examined rather than only one backend's emitter.

The key semantic requirement is that eval STRING inherits the caller's lexical hints, including strict 'vars', while still allowing explicit no strict 'vars' to disable the check.

Related issue search

Issue #1302, “JVM backend rejects valid @$ glob dereference under strict vars,” is related to strict-vars handling but is not a duplicate. It covers a false positive for glob-dereference syntax; this issue covers missing strict-vars inheritance inside string eval and affects both backends.

Acceptance criteria

• The minimal reproducer fails inside eval STRING under use strict on both JVM and interpreter backends.
• no strict 'vars' continues to allow the same eval expression.
• Lexically declared variables and explicitly declared package variables remain usable inside eval strings.
• Exporter::Easy 0.18's full 72-test suite passes on both backends.
• Add permanent project-owned regression coverage for strict-vars inheritance in string eval.