[perl #131187] [REGEX] Regression leading to incorrect capture when an action method is present
# New Ticket Created by Jonathan Worthington
# Please include the string: [perl #131187]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=131187 >
This is golfed from a File::Ignore regression. This reproduces it:
grammar Parser {
token TOP { + }
proto token matcher { * }
token matcher:sym<[]> { '[' <( <-[\]]>+ )> ']' }
token matcher:sym { <-[/*?[]>+ }
}
class RuleCompiler {
# Simply commenting out this causes the matcher:sym to get the
.txt it should. With
# this, it gets ].txt instead.
method matcher:sym<[]>($/) { }
}
say Parser.parse('[AB].txt', :actions(RuleCompiler));
Commenting out the action method makes the final match tree correct.
Without it, the match tree ends up with the second matcher wrongly
capturing the ].
I've had trouble bisecting it due to unbuildable commits; the log is here:
https://gist.github.com/Whateverable/119eb26d8ca245bf59ec05bc014c9fc2
It was fine in 2017.03 and broken in 2017.04, perhaps around the time of
the uncurse merge. I'm somewhat suspecting that, since it unified Match and
Cursor. This code may be a tricky edge case for the unification since it
uses the <( and )> constructs, which make the captured text and the text
matched by the cursor differ.
[perl #131120] [BUG] Junctions don't autothread some methods correctly
Em Fri, 07 Apr 2017 10:49:02 -0700, c...@zoffix.com escreveu:
> Some methods don't seem to get autothreaded correctly. Str does have
> .Numeric, but when junctioned, it doesn't seem to be reachable:
>
>
> $ perl6 -e 'say any("42",42).Int'
> any(42, 42)
>
> $ perl6 -e 'say any("42",42).Numeric'
> Cannot resolve caller Numeric(Str: ); none of these signatures match:
> (Mu:U \v: *%_)
> in block at -e line 1
>
> $ perl6 -e 'say any("42",42).Real'
> Cannot resolve caller Real(Str: ); none of these signatures match:
> (Mu:U \v: *%_)
> in block at -e line 1
>
> $ perl6 -e 'say "42".Numeric'
> 42
>
> $ perl6 -e 'say "42".Real'
> 42
>
> $ perl6 -v
> This is Rakudo version 2017.03-153-gb1e7a01 built on MoarVM version
> 2017.03-87-g5d73bf4
> implementing Perl 6.c.
That's not problem only on Int:
$ ./perl6 -e 'say any(42, 42.0).Numeric'
Cannot resolve caller Numeric(Int: ); none of these signatures match:
(Mu:U \v: *%_)
in block at -e line 1
$ ./perl6 -e 'say any(42.0, 42).Numeric'
Cannot resolve caller Numeric(Rat: ); none of these signatures match:
(Mu:U \v: *%_)
in block at -e line 1
[perl #131123] [BUG] Useless use of useless use in smartmatch + block + try
Em Fri, 14 Apr 2017 14:12:54 -0700, fernandocor...@gmail.com escreveu:
> Em Fri, 07 Apr 2017 19:59:42 -0700, c...@zoffix.com escreveu:
> >
> > m: say so 42 ~~ { try $_ == 5 }
> > rakudo-moar af50e0: OUTPUT: «WARNINGS for :Useless
> > use
> > of "==" in expression "$_ == 5" in sink context (line 1)False»
> >
> > m: say so 42 ~~ { $_ == 5 }
> > rakudo-moar af50e0: OUTPUT: «False»
>
>
> I think the problem is only with block + try...
>
> m: say {try 5 == 5}()
> combined, experimental evalbot rakudo-moar 7f73f9: OUTPUT:
> «WARNINGS for :Useless use of "==" in expression "5 == 5" in
> sink context (line 1)True»
try with a block doesn't warn:
Fernando Corrêa de Oliveira m: say {try {5 == 5}}()
<•camelia> combined, experimental evalbot rakudo-moar 624fe8: OUTPUT: «True»
[perl #131182] [BUG] Item contextualization fails in in map process
On Fri, 21 Apr 2017 08:53:44 -0700, c...@zoffix.com wrote:
> On Thu, 20 Apr 2017 08:39:41 -0700, cookbook_...@yahoo.co.jp wrote:
> > See the following results:
> >
> >
> > $ perl6 -e 'say (1..10).map({ { :a($_) } });'
> > (a => 1 a => 2 a => 3 a => 4 a => 5 a => 6 a => 7 a => 8 a => 9 a =>
> > 10)
> >
> > $ perl6 -e 'say (1..10).map({ ${ :a($_) } });'
> > (-> ;; $_? is raw { #`(Block|57168408) ... } -> ;; $_? is raw {
> > #`(Block|57168480) ... } -> ;; $_? is raw { #`(Block|57168552) ... }
> > -> ;; $_? is raw { #`(Block|57168624) ... } -> ;; $_? is raw {
> > #`(Block|57168696) ... } -> ;; $_? is raw { #`(Block|57168768) ... }
> > -> ;; $_? is raw { #`(Block|57168840) ... } -> ;; $_? is raw {
> > #`(Block|57168912) ... } -> ;; $_? is raw { #`(Block|57168984) ... }
> > -> ;; $_? is raw { #`(Block|57169056) ... })
> >
> >
> > I think the 2nd example should return the same result as the 1st
> > example.
> >
> > $ perl6 --version
> > This is Rakudo version 2017.03-217-ge681498 built on MoarVM version
> > 2017.03-115-ge8231a3
> > implementing Perl 6.c.
>
>
>
> Thank you for the report, however this is not a bug.
>
> In the first case, the bare block simply gets evaluated right away and
> its result (a Pair) is returned. In the second case, you're itemizing
> that block, so the block itself gets returned. You can achieve the
> same by, say, using a pointy block, which also won't get evaluated
> right away:
>
> say (1..10).map({ -> { :a($_) } });
> (-> { #`(Block|58087136) ... } -> etc
>
> I'm only guessing here, but I suspect you wanted the map to return a
> bunch of 1-element hashes? Like:
>
> say (1..10).map: { %(:a($_)) };
> ({a => 1} {a => 2} {a => 3} {a => 4} {a => 5} {a => 6} {a => 7} {a =>
> 8} {a => 9} {a => 10})
>
> Note how I used the %() coercer instead of bare curlies. This is due
> to there being an ambiguity in curlies: do they mean a block or a
> hash? When `$_` variable is used inside, the compiler treats it as a
> block, which is why in your case it evaluated the block or returned it
> when you tried to itemize it.
>
> So another way to get a bunch of 1-element hashes is to not use the
> `$_` inside, but some other variable:
>
> say (1..10).map: -> $a { {:$a} };
> ({a => 1} {a => 2} {a => 3} {a => 4} {a => 5} {a => 6} {a => 7} {a =>
> 8} {a => 9} {a => 10})
>
> Cheers,
> ZZ
Thanks for your neat explanation.
> I'm only guessing here, but I suspect you wanted the map to return a bunch of
> 1-element hashes ?
Yes! I tried to create a bunch of 1-element hashes.
I'm sorry, the 1st example was incorrect for showing what I expected.
