Change 33724 by nicholas@mouse-mill on 2008/04/22 15:01:52
Note that Rafael did the key elsif() line number TODO, and we're not
certain that solving the general case is worth it.
Affected files ...
... //depot/perl/pod/perltodo.pod#224 edit
Differences ...
==== //depot/perl/pod/perltodo.pod#224 (text) ====
Index: perl/pod/perltodo.pod
--- perl/pod/perltodo.pod#223~33711~ 2008-04-18 05:43:27.000000000 -0700
+++ perl/pod/perltodo.pod 2008-04-22 08:01:52.000000000 -0700
@@ -924,17 +924,18 @@
} elsif ($undef == 0) {
}
-produces this output
+used to produce this output:
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
Use of uninitialized value in numeric eq (==) at wrong.pl line 4.
-Clearly the line of the second warning is misreported - it should be line 5.
-
-The problem arises because there is no nextstate op between the execution of
-the C<if> and the C<elsif>, hence C<PL_curcop> still reports that the currently
-executing line is line 4. The solution might be to inject (somehow) more
-nextstate ops, one for each C<elsif>.
+where the line of the second warning was misreported - it should be line 5.
+Rafael fixed this - the problem arose because there was no nextstate OP
+between the execution of the C<if> and the C<elsif>, hence C<PL_curcop> still
+reports that the currently executing line is line 4. The solution was to inject
+a nextstate OPs for each C<elsif>, although it turned out that the nextstate
+OP needed to be a nulled OP, rather than a live nextstate OP, else other line
+numbers became misreported. (Jenga!)
The problem is more general than C<elsif> (although the C<elsif> case is the
most common and the most confusing). Ideally this code
@@ -968,6 +969,9 @@
conjunction with L</repack the optree>, as that is already copying/reallocating
all the OPs)
+(Although I should note that we're not certain that doing this for the general
+case is worth it)
+
=head2 optimize tail-calls
Tail-calls present an opportunity for broadly applicable optimization;
End of Patch.