Data::Dumper::Simple 0.11 fails because Filter::Simple source filtering is not applied correctly

Start by running jperl -Ilib t/10dump.t and the corresponding --interpreter command, then compare the failing upstream tests t/20import.t, t/30autowarn.t, and t/40noparens.t. Read the source-filter registration and application after use statements, especially the Filter::Util::Call/Filter::Simple integration and remaining-source re-tokenization. Done means all four tests pass on both backends and a focused project-owned regression test covers the filter behavior.

Summary

Data::Dumper::Simple v0.11 fails its upstream test suite under PerlOnJava because its Filter::Simple source filter does not transform calls made after the module is imported.

This was observed in CPAN random tester run 20260913-205737-64746.

Reproduction

The upstream test suite passes under system Perl:

• 4 substantive test programs passed
• 35 tests passed in total
• The optional POD tests were skipped because their optional dependencies/files were unavailable

The same upstream tests fail under both PerlOnJava backends:

• JVM backend: t/10dump.t, t/20import.t, t/30autowarn.t, and t/40noparens.t fail
• Interpreter backend: the same four tests fail

Representative commands:

jperl -Ilib t/10dump.t
jperl --interpreter -Ilib t/10dump.t

Observed failures

• t/10dump.t: Undefined subroutine &main::Dumper
• t/20import.t: Undefined subroutine &main::frobnitz
• t/30autowarn.t: Undefined subroutine &main::Dumper
• t/40noparens.t: Global symbol "$hash" requires explicit package name

Each failing test reports that it ran only its initial use_ok test before aborting.

Expected behavior

use Data::Dumper::Simple installs a Filter::Simple source filter. Calls such as:

Dumper($scalar, @array, %hash)

should be rewritten at compile time to an equivalent Data::Dumper->Dump call. The as => 'frobnitz' and autowarn options, as well as no-parentheses syntax, should work as they do under system Perl.

Initial diagnosis

The distribution is pure Perl and has no XS, native-library, display, network-service, or other platform prerequisite involved in these tests. The failures occur identically on the JVM and interpreter backends, indicating a shared frontend/source-filter compatibility problem rather than a backend-specific runtime issue.

The module uses Filter::Simple with FILTER_ONLY executable. The missing generated subroutine calls indicate that the filter is either not being applied to the remaining source after the import or its transformed source is not being correctly re-tokenized/compiled. The strict-vars error in t/40noparens.t is consistent with the no-parentheses source-filter path failing to produce the expected transformed expression.

Relevant implementation areas include source-filter registration and application after use statements, especially the Filter::Util::Call/Filter::Simple integration and remaining-source re-tokenization in the frontend.

Acceptance criteria

• All four substantive Data::Dumper::Simple test programs pass on the JVM backend.
• The same tests pass on the interpreter backend.
• as => 'frobnitz', autowarn, and no-parentheses calls are covered.
• Add a project-owned focused regression test for the underlying source-filter behavior; retain the upstream distribution tests as integration coverage.

Environment

• CPAN random tester run: 20260913-205737-64746
• Distribution: Data-Dumper-Simple-0.11
• Affected backends: JVM and interpreter
• System Perl: full substantive suite passes