PrereqScanner TestNeeds loses quoted module names and version literals
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
Research direction
Start with the failing upstream t/test.t cases and reproduce them first with system Perl, then on both JVM and interpreter backends. Trace quoted and numeric literals through the parser/compiler value path and the PPI/PPIx::Literal compatibility layer. Done means project-owned regression coverage preserves multiple module names and the 5.020 version consistently on both backends.
Written by the indexing model from the issue text.
Description
Summary
Perl::PrereqScanner::Scanner::TestNeeds v0.001 regressed on PerlOnJava.
The scanner no longer preserves quoted module names or Perl version literals
when processing use Test::Needs statements.
The regression reproduces identically on both the JVM backend and the
interpreter backend.
CPAN evidence
- Distribution:
Perl-PrereqScanner-Scanner-TestNeedsv0.001 - Module:
Perl::PrereqScanner::Scanner::TestNeeds - CPAN run:
20260915-125610-17469 - Result: 2/3 assertions failed; 1/2 test programs failed
- Previous passing result: 2026-08-27, commit
4ebea751e - Standard Perl: complete upstream suite passes, 9 tests
- PerlOnJava: 2 assertions fail, followed by an invalid-version exception
- Native code: none in the target distribution or its relevant dependencies
The failing upstream tests are t/test.t assertions for one and multiple
module prerequisites. The failure occurs after the module's load test passes.
Reproduction
use Perl::PrereqScanner;
my $scanner = Perl::PrereqScanner->new({ scanners => ['TestNeeds'] });
my $prereqs = $scanner->scan_string(
q{use Test::Needs 'Local::Module1'}
);
use Data::Dumper;
print Dumper($prereqs->as_string_hash);
Expected under standard Perl:
{ 'Local::Module1' => 0 }
Observed on both PerlOnJava backends:
{ '' => 0 }
The version-literal case also differs:
$scanner->scan_string(q{use Test::Needs { perl => 5.020 }});
Expected:
{ perl => '5.020' }
Observed:
{ perl => '5.000' }
The upstream test then aborts with:
Can't convert '': Invalid version format (version required)
Backend scope
The exact upstream test command fails on both execution backends with the
same results:
- JVM backend:
Local::Module1andLocal::Module2are missing from the
prerequisite map; the test ends with invalid-version parsing. - Interpreter backend: the same missing module names and invalid-version
failure occur.
Likely ownership
The target module's implementation delegates source literal handling to
PPIx::Literal and prerequisite accumulation to Perl::PrereqScanner. The
failure is not in the upstream distribution: its complete suite passes under
standard Perl.
The PerlOnJava result suggests a shared literal/value representation defect:
- quoted string literals are converted to an empty string;
- version-like numeric literals lose their significant digits and become
5.000instead of5.020; - the resulting values are then passed into the scanner and version parser.
The regression should be investigated in the parser/compiler value path and
the PPI/PPIx::Literal compatibility layer, rather than by changing the CPAN
module or its tests.
Impact
This breaks static prerequisite scanning for Test::Needs, causing module
requirements to be silently recorded under the wrong name or omitted. It can
also misrepresent Perl version requirements, potentially allowing an
incorrect prerequisite set to pass validation or causing downstream tools to
abort with invalid-version errors.
Because Perl::PrereqScanner is used by CPAN tooling and distribution build
systems, the defect may affect more scanners and prerequisite declarations
than this small test distribution exposes.
Expected fix
Preserve the exact value and type of PPI/PPIx::Literal results when scanning
quoted strings and numeric/version literals. In particular:
use Test::Needs 'Local::Module1'must produce
Local::Module1 => 0.- Multiple quoted module names must all be retained.
perl => 5.020must retain the Perl version value5.020.- JVM and interpreter backends must agree.
Add permanent project-owned regression coverage, validated first with system
Perl, for quoted module names, multiple module names, and Perl version
literals.
Deduplication
GitHub searches were performed for PPIx::Literal, Perl::PrereqScanner,
Test::Needs, the empty-string prerequisite symptom, and the 5.020 version
conversion.
No existing issue directly covers this regression. Existing parser/runtime
issues found by the search concern unrelated behaviors, including DBI trace,
Unicode regex handling, typeglob localization, and hash-reference aliasing.
This report is therefore not a duplicate.
- Dominant language
- Perl
- Stars
- 64
- Forks
- 6
- Avg merge
- 5h 11m
- Merged PRs (30d)
- 168
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from fglock/PerlOnJava
-
area:cpan-port area:unicode bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
fglock/PerlOnJava#1341 ·
-
area:backend area:runtime enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
fglock/PerlOnJava#1494 ·
-
area:backend area:runtime enhancement
Difficulty 4/5 3-5 days Newbie friendliness 45/100
fglock/PerlOnJava#1492 ·
-
area:parser bug
Difficulty 3/5 1-2 days Newbie friendliness 65/100
fglock/PerlOnJava#1491 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
fglock/PerlOnJava#1487 ·
All issues in fglock/PerlOnJava
Similar issues
-
documentation Needs Triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
trizen/youtube-viewer#456 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
connectivity Open
Difficulty 1/5 Under an hour Newbie friendliness 80/100
-
Common US ingredient names are not recognized, so about 12.4k US products miss an allergen warning Open
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
openfoodfacts/openfoodfacts-server#14657 · 4 comments ·