avoid $a["foo" eq $x ? 0 : 1] warning

RT #123609

The compiling code that looks for OP_MULTIDEREF candidates was
unconditionally numifying the first constant of an array index expression,
before it had confirmed that the expression consisted solely of a const.
So in something like

    $a['foo' eq $x ? 0 : 1]

the 'foo' would be numified and give a spurious warning:

    Argument "foo" isn't numeric

This commit fixes it by skipping the OP_MULTIDEREF optimisation if the
array index const isn't SvIOK(). In theory this means that something like

    $r->["0"]

no longer gets optimised, but I think we can live with that :-)

It also means that the test for the const being SvROK is no longer
necessary.

(Finally, I moved the declaration of the iv var down a few scopes as it
wasn't being used elsewhere in the wider scope.)

1 files changed, 21 insertions, 1 deletions

diff --git a/t/op/multideref.t b/t/op/multideref.t
index 1ae0843aa8..b094c8f23a 100644
--- a/t/op/multideref.t
+++ b/t/op/multideref.t
@@ -18,7 +18,7 @@ BEGIN {
 use warnings;
 use strict;
 
-plan 56;
+plan 58;
 
 
 # check that strict refs hint is handled
@@ -185,3 +185,23 @@ sub defer {}
     defer($h{foo}{bar});
     ok(!exists $h{foo}{bar}, "defer");
 }
+
+# RT #123609
+# don't evalulate a const array index unlesss its really a const array
+# index
+
+{
+    my $warn = '';
+    local $SIG{__WARN__} = sub { $warn .= $_[0] };
+    ok(
+        eval q{
+            my @a = (1);
+            my $arg = 0;
+            my $x = $a[ 'foo' eq $arg ? 1 : 0 ];
+            1;
+        },
+        "#123609: eval"
+    )
+        or diag("eval gave: $@");
+    is($warn, "", "#123609: warn");
+}