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

首先运行 jperl -Ilib t/10dump.t 和对应的 --interpreter 命令，然后比较失败的 upstream 测试 t/20import.t、t/30autowarn.t 和 t/40noparens.t。阅读 use 语句之后的 source-filter 注册和应用，尤其是 Filter::Util::Call/Filter::Simple 集成以及剩余源代码的重新标记化。完成的标准是四个测试在两个后端上都通过，并且有一个聚焦的项目自有回归测试覆盖该 filter 的行为。

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