fix range op under aborted constant folding

When constant-folding a range/flipflop construct, the op_next threading
of peephole optimisation caused multiple ops in the construct to have
a null op_next, because the final (and top-level) op in the construct
is a null op.  This meant that simple restoration of the top-level
op's op_next after execution wouldn't get it back into a fit state
to be composed with other ops.  In the event that the range construct
couldn't be constant-folded this made it compile to a broken optree.
If it couldn't be constant-folded but could actually be executed, for
example because it generated a warning, this meant the brokenness would
be encountered at runtime.  Execution would stop after the range op,
because of the null op_next.

To avoid this, temporarily mark the null op as a custom op during the
peephole optimisation that supports the execution for constant-folding.
This prevents it being op_next-threaded out, so simple op_next restoring
then works.  If the constant-folding is aborted, it compiles to an
operational optree.  However, the suppression of duplicate peephole
optimisation means that the null op is never ultimately threaded out
as it should be.  For the time being, this stands as a cost of failed
constant-folding of range constructs.

Fixes [perl #130639].

1 files changed, 4 insertions, 1 deletions

diff --git a/t/comp/fold.t b/t/comp/fold.t
index a875b5bdef..a72394e8cf 100644
--- a/t/comp/fold.t
+++ b/t/comp/fold.t
@@ -4,7 +4,7 @@
 # we've not yet verified that use works.
 # use strict;
 
-print "1..34\n";
+print "1..35\n";
 my $test = 0;
 
 # Historically constant folding was performed by evaluating the ops, and if
@@ -189,3 +189,6 @@ $b = 0;
 $a = eval 'my @z; @z = 0..~0 if $b; 3';
 is ($a, 3, "list constant folding doesn't signal compile-time error");
 is ($@, '', 'no error');
+
+$a = eval 'local $SIG{__WARN__} = sub {}; join("", ":".."~", "z")';
+is ($a, ":z", "aborted list constant folding still executable");