Parser rejects our self-reference in its initializer under strict vars
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
Rechercherichtung
Start by tracing how our declarations are handled and how strict 'vars' resolves initializer references in both the JVM and interpreter backends. Reproduce with our $V = $V = 119; under strict vars and compare with system Perl. Done when both backends compile the case and leave $V equal to 119.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Summary
The parser rejects a valid our declaration when its initializer reads the variable being declared under strict 'vars'. This breaks CPAN distribution Text-Template 1.61: t/delimiters.t stops at compile time with Global symbol "$V" requires explicit package name, before running its assertions. System Perl 5.42.2 accepts the source, and the complete upstream distribution suite passes there (22 files, 184 tests). Both PerlOnJava backends reject it.
Root cause
The declaration's initializer is resolved before the our variable is entered into the current lexical symbol table. Perl makes the our alias visible in the declaration's initializer, so the self-assignment in this valid initializer must resolve to the package variable. The package glob being materialized during declaration handling is not sufficient: strict-variable resolution uses the lexical symbol table and reports the RHS $V as undeclared.
This was independently reproduced with the one-line case in the comment. It fails under both the JVM and interpreter backends and succeeds under system Perl. The failure is included in archived CPAN run 20261104-151051-20617.
Expected behavior
our $V = $V = 119; compiles under use strict and leaves $V equal to 119, as it does in system Perl.
- Vorherrschende Sprache
- Perl
- Sterne
- 65
- Forks
- 8
- Ø Merge
- 5 Std. 45 Min.
- Gemergte PRs (30 T.)
- 184
Entwicklungsumgebung
- Enthält ein Dockerfile oder eine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus fglock/PerlOnJava
-
area:runtime documentation enhancement
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
fglock/PerlOnJava#1579 ·
Maintainer antworten meist innerhalb von 1 Tag
-
area:backend bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 55/100
fglock/PerlOnJava#1981 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
area:runtime bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 57/100
fglock/PerlOnJava#1980 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
area:cpan-port bug
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
fglock/PerlOnJava#1962 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 52/100
fglock/PerlOnJava#1961 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in fglock/PerlOnJava
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
libwww-perl/HTTP-Message#236 ·
-
1.severity: security
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
Maintainer antworten meist innerhalb von 2 Tagen
-
wave-followup
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
benchmarks/README: 'perl BNG2.pl model.bngl' runs the whole protocol, not just generate_networkOffendocumentation
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag