This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Allow void padrange even without nextstate
authorFather Chrysostomos <sprout@cpan.org>
Fri, 17 Oct 2014 20:56:52 +0000 (13:56 -0700)
committerFather Chrysostomos <sprout@cpan.org>
Fri, 17 Oct 2014 20:57:24 +0000 (13:57 -0700)
commit5b807558721d4a1b9a2121285e81b695d4b5025b
tree5c5637a09e7986478fa63aaef4e808125339e3be
parentde4d3e9afc1a641a8e2646dfc1104c961e49c70d
Allow void padrange even without nextstate

This allows the padrange optimisation to happen with code like this:

    my ($a, $b), our $c;

The padrange optimisation looks for:

    list
      pushmark
      padsv
      padsv
      ...
    nextstate

if it is in void context.

padsv pushes an sv on to the stack, and then nextstate resets the
stack.  padrange doesn’t bother pushing in void context, which is why
this optimisation was written this way.

However, there are various ops that don’t bother touching the stack in
void context, for efficiency; conversely, there are many that do for
simplicity’s sake.  In all cases, however, things pushed in void con-
text are subsequently reset, usually by list/nextstate/leavesub,
before they can accidentally become part of a list.  So whether pad-
range pushes SVs or not in void context is irrelevant, and it does not
matter whether there is a nextstate op.

Further, this optimisation also allowed:

  ex-list
    pushmark
    ...

pushmark and list ops cancel each other out in list and void context.
padrange does not push a mark in void context, so the list is removed
from the execution chain.  That was also happening for a nulled list,
which is incorrect, as that means a lone pushmark is being removed.  I
don’t believe ex-list+pushmark ever occurs in void context, but if it
does then this code was wrong.
op.c