Fewer false positives for %hash{$scalar} warning

Instead of warning in the lexer, flag the op and then warn in op.c,
when the op tree is available, so we don’t end up warning for actual
lists or for sub calls.

Also, only warn in scalar context, as in list context $hash{$scalar}
and %hash{$scalar} do different things.

In op.c we no longer have easy access to the source code, so recon-
struct the hash/array access based on the op tree.  This means
%hash{foo} becomes %hash{"foo"}.  We only reconstruct constant keys,
so %hash{++$x} becomes %hash{...}.  This also corrects erroneous
dumps, like %hash{"} for %hash{"}"}.

Instead of triggering the warning solely based on the op tree, we
still keep the heuristic in toke.c, so that common workarounds for
that warning (e.g., {q<key>} and {("key")}) continue to work.

The heuristic in toke.c is tweaked to avoid warning for qw().

In a future commit I plan to extend this to the existing @array[0] and
@hash{key} warnings, to avoid false positives.

1 files changed, 7 insertions, 0 deletions

diff --git a/perly.y b/perly.y
index accc95dc34..6b196469e4 100644
--- a/perly.y
+++ b/perly.y
@@ -1210,6 +1210,9 @@ term	:	termbinop
 				    newLISTOP(OP_KVASLICE, 0,
 					list($3),
 					ref(oopsAV($1), OP_KVASLICE)));
+			  if ($$ && $1)
+			      $$->op_private |=
+				  $1->op_private & OPpSLICEWARNING;
 			  TOKEN_GETMAD($2,$$,'[');
 			  TOKEN_GETMAD($4,$$,']');
 			}
@@ -1230,6 +1233,9 @@ term	:	termbinop
 				    newLISTOP(OP_KVHSLICE, 0,
 					list($3),
 					ref($1, OP_KVHSLICE)));
+			  if ($$ && $1)
+			      $$->op_private |=
+				  $1->op_private & OPpSLICEWARNING;
 			    PL_parser->expect = XOPERATOR;
 			  TOKEN_GETMAD($2,$$,'{');
 			  TOKEN_GETMAD($4,$$,';');
@@ -1435,6 +1441,7 @@ ary	:	'@' indirob
 
 hsh	:	'%' indirob
 			{ $$ = newHVREF($2);
+			  if ($$) $$->op_private |= IVAL($1);
 			  TOKEN_GETMAD($1,$$,'%');
 			}
 	;