Apply scalar context to LSLICE and ASLICE more thoroughly

[richardleach]

Perl_scalar is used to apply scalar context to OPs. This process can also
result in some KID OPs being nulled out. However, this has not happened
to OP_LSLICE and OP_ASLICE trees to the extent that seems possible.

For example, with my $x = (1,2,3), the resulting optree (pre-peephole
optimisation) is:

2     <;> nextstate(main 2 -e:1) v:%,us,{,fea=15 ->3
7     <2> sassign vKS/2 ->8
5        <@> list sKP ->6
3           <0> pushmark v ->4
-           <0> ex-const v ->-
-           <0> ex-const v ->4
4           <$> const[IV 3] s ->5
6        <0> padsv[$x:2,3] sRM*/LVINTRO ->7

The interpreter only needs to execute the one CONST OP in scalar
context to get the correct behaviour.

This PR adds OP_LSLICE and OP_ASLICE cases to the switch
statement within Perl_scalar so that the same optimisation
occurs for those optrees. Previously, it did not, meaning that
unnecessary operations would be performed at runtime, with the
results then just ignored.

Note that the following seem desirable, but would need a broader
refactoring of Perl_scalar, and are so out of scope of this PR:

• Discarding, rather than just nulling, the unnecessary CONST OPs
• Extracting the remaining valid OP and discarding the list/ex-list container and its pushmark OP.

i.e. Future work could try to get the above optree down to:

2     <;> nextstate(main 2 -e:1) v:%,us,{,fea=15 ->3
5     <2> sassign vKS/2 ->6
3        <$> const[IV 3] s ->4
4        <0> padsv[$x:2,3] sRM*/LVINTRO ->5

---

• This set of changes requires a perldelta entry, and it is included.

[tonycoz]

This changes behaviour beyond the added warnings:

# system perl 5.36
$ perl -WE '@x = "a" .. "d"; sub f {} my $y = @x[2, 3, f()]; say $y // "undef"'
d
# this change
$ ./perl -Ilib -WE '@x = "a" .. "d"; sub f {} my $y = @x[2, 3, f()]; say $y // "undef"'
Useless use of a constant (2) in void context at -e line 1.
Useless use of a constant (3) in void context at -e line 1.
undef

Similarly for list slice:

$ perl -WE 'sub f {} my $y = ("a" .. "d")[2, 3, f()]; say $y // "undef"'
d
$ ./perl -Ilib -WE 'sub f {} my $y = ("a" .. "d")[2, 3, f()]; say $y // "undef"'
Useless use of a constant (2) in void context at -e line 1.
Useless use of a constant (3) in void context at -e line 1.
undef

[richardleach]

Thanks Tony. I'll dig into why.

[richardleach]

I've thought round this and I understand it better now.

Is the following behaviour correct? (As in, it is a construct that looks similar but is not and is not expected to behave the same, or is there an inconsistency?)

$ perl -E 'sub foo {} my $x = (1,2,foo()); say $x // "undef";'
undef

For this PR, I suppose LSLICE and ASLICE could have their own scalar optimization that doesn't warn but null's any stack pushing op (e.g. CONST, PADSV) that has another of the same following it? Not entirely sure if that would be worthwhile or not....

[tonycoz]

That behaviour is correct, but unlike that case the indexes for a slice are in list context.

You can check that in older perls by checking wantarray in f() in my example.

# 5.36
$ perl -WE 'sub f {say wantarray ? "LIST" : "SCALAR"; ()} my $y = ("a" .. "d")[2, 3, f()]; say $y // "undef"'
LIST
d

Another one I haven't tested (and I've cleaned my build of your branch) is how this patch handles an array instead of a function call:

# 5.36
$ perl -WE 'my @i; my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
d
$ perl -WE 'my @i=(1); my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
b

[richardleach]

Another one I haven't tested (and I've cleaned my build of your branch) is how this patch handles an array instead of a function call:

# 5.36
$ perl -WE 'my @i; my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
d
$ perl -WE 'my @i=(1); my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
b

$ ./perl -Ilib -WE 'my @i; my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
Useless use of a constant (2) in void context at -e line 1.
Useless use of a constant (3) in void context at -e line 1.
undef

./perl -Ilib -WE 'my @i=(1); my $y = ("a" .. "d")[2, 3, @i]; say $y // "undef"'
Useless use of a constant (2) in void context at -e line 1.
Useless use of a constant (3) in void context at -e line 1.
b

[richardleach]

I'm going to do a separate PR to include the tests suggested by Tony, then close this one down. Not sure it's worth the effort of partially optimising at this stage.