$ ./Porting/bisect.pl --target=miniperl --start=v5.16.3 --end=v5.26.0 --expect-fail -e 'use warnings FATAL=>"all"; sub X () {2,3}; my @a=("a".."z"); print @a[X]' ... commit 429a25554a608b64c0ee46c1ffe19bab3718a3c8 Author: Father Chrysostomos Date: Sat Sep 14 17:23:11 2013 -0700 Reduce false positives for @hsh{$s} and @ary[$s] warnings This resolves tickets #28380 and #114024. Commit 95a31aad5 did something similar to this for the new %hash{...} syntax. This commit extends it to @ slices and combines the two code paths. The heuristics in toke.c can easily produce false positives. So the op is flagged as being a candidate for the warning. Then when op.c has the op tree available, it examines it to see whether the heuristic may have been a false positive. This avoids bugs with qw "foo bar baz" and sub calls triggering the warning. The source code is no longer available for the warning, so we recon- struct it from the op tree, skipping the subscript if it is anything other than a const op. This means that @hash{$foo} comes out as @hash{...} and @hash{foo} as @hash{"foo"}. It also meeans that @hash{"]"} is displayed correctly instead of as @hash{"]. Commit 95a31aad5 also modified the heuristic for %hash{...} to exempt qw altogether. But it did not exempt it if it was preceded by a tab. So this commit rectifies that. This commit also improves the false positive detection by exempting any ops returning lists that can get past toke.c’s heuristic. I went through the entire list of ops, but I may have missed some. Also, @ slices on the lhs of = are exempt, as they change the context and are hence actually useful. $ git tag --contains 429a25554a608b6 ... v5.20.0 ...