Allow Moo constant closures capturing lexical values
还没有人认领这个 Issue。
评估
调研方向
Start with Moo/_Utils.pm around lines 216 and 221, then trace the BEGIN block and its string eval into PerlOnJava's constant-subroutine and lexical-capture handling. Reproduce with use Moo; on both backends and compare with standard Perl. Done means Moo loads successfully without the invalid constant-closure diagnostic and the MooX::Options::Actions basic test runs.
由索引模型根据 Issue 内容生成。
描述
Summary
PerlOnJava cannot compile Moo because it rejects the generated constant closure in Moo::_Utils. This prevents MooX::Options::Actions 0.001 from loading, even though the complete upstream suite passes under standard Perl.
Reproduction
The failure was found in CPAN random run 20260921-124328-13959 while testing MooX::Options::Actions 0.001. Its dependency chain includes MooX::Options 4.103 and Moo.
The smallest reproducer is:
use Moo;
On both the JVM backend and the interpreter backend, PerlOnJava reports:
Constants from lexical variables potentially modified elsewhere are no longer permitted
at Moo/_Utils.pm line 216.
BEGIN failed--compilation aborted at Moo/_Utils.pm line 221
Compilation failed in require
The error is raised while compiling Moo's BEGIN block that constructs a constant helper from a lexical expression involving ${^GLOBAL_PHASE}. Standard Perl accepts and loads this code.
CPAN evidence
The standard-Perl oracle passes the upstream distribution:
t/basic.t .............. ok
All tests successful.
Files=2, Tests=8
Result: PASS
Under PerlOnJava, t/author-pod-syntax.t is skipped as intended, but t/basic.t aborts before running any tests:
t/basic.t ..............
Dubious, test returned 255
No subtests run
Files=2, Tests=0
The dependency installation completed successfully. This is not a missing dependency or timeout; the failure occurs in PerlOnJava's bundled Moo implementation during compilation.
Expected behavior
PerlOnJava should accept Moo's generated constant subroutine and load Moo successfully. The diagnostic should not be emitted for the valid lexical-closure pattern used by current Moo releases.
Suspected area
Compiler handling of constant subroutines and lexical capture analysis, especially code generated by string eval inside a BEGIN block. The implementation appears to reject a pattern that standard Perl permits when a lexical value is captured by a constant subroutine.
Environment and scope
- Distribution:
MooX::Options::Actions0.001 - Dependencies:
MooX::Options4.103,Moo - PerlOnJava backends: JVM and interpreter
- PerlOnJava reports Perl 5.044001
- Standard Perl oracle: Perl 5.42.2 on macOS
- Native/XS code in the affected distribution: none
- Reverse-dependency analysis: not applicable; this is a pure-Perl compatibility failure
This failure is separate from the unrelated Ambiguous call resolved as CORE::try() warnings emitted by the same run.
- 主要语言
- Perl
- 星标
- 64
- 派生
- 6
- 平均合并
- 5 小时 38 分钟
- 30 天内合并 PR
- 170
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
fglock/PerlOnJava 的其他 Issue
-
area:cpan-port area:unicode bug
难度 2/5 1-3 小时 新手友好度 88/100
fglock/PerlOnJava#1341 ·
-
area:backend area:runtime bug
难度 4/5 3-5 天 新手友好度 45/100
fglock/PerlOnJava#1511 ·
-
area:backend area:cpan-port bug
难度 4/5 3-5 天 新手友好度 45/100
fglock/PerlOnJava#1508 · 1 条评论 ·
-
area:cpan-port area:platform enhancement
难度 5/5 一周以上 新手友好度 30/100
fglock/PerlOnJava#1507 ·
-
bug
难度 4/5 3-5 天 新手友好度 45/100
fglock/PerlOnJava#1506 ·
查看 fglock/PerlOnJava 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
-
documentation Needs Triage
难度 2/5 1-3 小时 新手友好度 75/100
-
难度 2/5 1-3 小时 新手友好度 75/100
trizen/youtube-viewer#456 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
connectivity 未关闭
难度 1/5 1 小时以内 新手友好度 80/100