Smart match goes wrong with array slice - precedence problem? #10580
Comments
From @epaCreated by @epa use 5.010; Oddly, this prints first lhs: a y0 z I expected it not to print 'first yes', since the LHS of the smart Or at the very least, I expected the 'first yes' and 'second yes' If I put brackets round the 'first yes' line, as say 'first yes' if ((@a[0 .. $#b]) ~~ @b); then the result is as I expect - but I can't see why the precedence Perl Info |
From @dglThis reminded me of some odd behaviour I had never had time to investigate. It's not really a precedence problem, the suggested workaround of adding parens (1,2,3) ~~ [1..3] # true This is because this compares the last item of the LHS with the array and 3 ~~ Looking at how smartmatch works underneath it actually takes a reference to the Patch attached. Although I'm not sure I like the approach of teaching David |
From @dgl0001-Fix-RT-77468-Smart-matching-on-slices.patchFrom bd4ff422615858ef8c733f2bdfbd942d00feabad Mon Sep 17 00:00:00 2001
From: David Leadbeater <dgl@dgl.cx>
Date: Sat, 28 Aug 2010 22:39:58 +0100
Subject: [PATCH] Fix RT #77468: Smart matching on slices
ref_array_or_hash did not take aslice or hslice OPs into account; wrap
them in an anonlist so that smart matching has a reference as it
expects.
---
op.c | 12 ++++++++++++
t/op/smartmatch.t | 26 +++++++++++++++++++++++++-
2 files changed, 37 insertions(+), 1 deletions(-)
diff --git a/op.c b/op.c
index 433face..a0fae09 100644
--- a/op.c
+++ b/op.c
@@ -5543,6 +5543,18 @@ S_ref_array_or_hash(pTHX_ OP *cond)
return newUNOP(OP_REFGEN,
0, mod(cond, OP_REFGEN));
+ else if(cond
+ && (cond->op_type == OP_ASLICE
+ || cond->op_type == OP_HSLICE)) {
+
+ /* anonlist now needs a list from this op, was previously used in
+ * scalar context */
+ cond->op_flags |= ~(OPf_WANT_SCALAR | OPf_REF);
+ cond->op_flags |= OPf_WANT_LIST;
+
+ return newANONLIST(mod(cond, OP_ANONLIST));
+ }
+
else
return cond;
}
diff --git a/t/op/smartmatch.t b/t/op/smartmatch.t
index f8a073b..f14e91c 100644
--- a/t/op/smartmatch.t
+++ b/t/op/smartmatch.t
@@ -73,7 +73,7 @@ my %keyandmore = map { $_ => 0 } @keyandmore;
my %fooormore = map { $_ => 0 } @fooormore;
# Load and run the tests
-plan tests => 335;
+plan tests => 351;
while (<DATA>) {
SKIP: {
@@ -484,6 +484,30 @@ __DATA__
@nums { 1, '', 12, '' }
! @nums { 11, '', 12, '' }
+# array slices
+ @nums[0..-1] []
+ @nums[0..0] [1]
+! @nums[0..1] [0..2]
+ @nums[0..4] [1..5]
+
+! undef @nums[0..-1]
+ 1 @nums[0..0]
+ 2 @nums[0..1]
+! @nums[0..1] 2
+
+ @nums[0..1] @nums[0..1]
+
+# hash slices
+ @keyandmore{qw(not)} [undef]
+ @keyandmore{qw(key)} [0]
+
+ undef @keyandmore{qw(not)}
+ 0 @keyandmore{qw(key and more)}
+! 2 @keyandmore{qw(key and)}
+
+ @fooormore{qw(foo)} @keyandmore{qw(key)}
+ @fooormore{qw(foo or more)} @keyandmore{qw(key and more)}
+
# UNDEF
! 3 undef
! 1 undef
--
1.6.3.3
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @rgarciaOn 28 August 2010 23:49, David Leadbeater <dgl@dgl.cx> wrote:
Thanks, applied to bleadperl as 329a333. |
|
@rgs - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#77468 (status was 'resolved')
Searchable as RT77468$
The text was updated successfully, but these errors were encountered: