Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

PrereqScanner TestNeeds loses quoted module names and version literals

Open
#1,396 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
42/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java, perl
Domain
backend, compilers

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

area:backend area:cpan-port area:parser area:runtime bug

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-TestNeeds v0.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::Module1 and Local::Module2 are 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.000 instead of 5.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:

  1. use Test::Needs 'Local::Module1' must produce
    Local::Module1 => 0.
  2. Multiple quoted module names must all be retained.
  3. perl => 5.020 must retain the Perl version value 5.020.
  4. 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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from fglock/PerlOnJava

All issues in fglock/PerlOnJava

Similar issues

More Perl issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.