Skip Menu |
Report information
Id: 126971
Status: new
Priority: 0/
Queue: perl6

Owner: Nobody
Requestors: peschwa [at] gmail.com
Cc:
AdminCc:

Severity: (no value)
Tag: Bug
Platform: (no value)
Patch Status: (no value)
VM: (no value)



Subject: [BUG] Rematching in a code assertion inside a regex doesn't recognize Match variable shorthands
02:03 < lucs> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$0 is now ", $0.WHAT) }> /) 02:03 <+camelia> rakudo-moar 091ee7: OUTPUT«$0 is now Nil␤True␤» [...] 02:05 < lucs> TimToady: So would that ^^ be a bug or a don't-do-that? [...] 02:06 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/ is now ", $0.WHAT) }> /) [...] 02:06 <+camelia> rakudo-moar 091ee7: OUTPUT«$/ is now Nil␤True␤» 02:06 < psch> huh 02:06 < psch> that seems wrong to me, at least 02:06 < psch> well, no 02:07 < psch> accessing $/ there is a "works sometimes" workaround for accessing the CURSOR special name [...] 02:07 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$¢ is now ", $¢.WHAT) }> /) 02:07 <+camelia> rakudo-moar 091ee7: OUTPUT«$¢ is now Nil␤True␤» [...] 02:08 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/ is now ", $/.WHAT) }> /) 02:08 <+camelia> rakudo-moar 091ee7: OUTPUT«$/ is now (Match)␤True␤» [...] 02:08 < psch> m: say so("a" ~~ / (.) <?{ $0 ~~ /'a'/ && say("\$/[0] is now ", $/[0].WHAT) }> /) 02:08 <+camelia> rakudo-moar 091ee7: OUTPUT«$/[0] is now Nil␤True␤» 02:08 < psch> lucs: the hunch is that the switch from Perl6::Grammar to NQP::P6Regex messes something up with accessing the different interpretations of $/ 02:09 < psch> as in, the code block inside the regex doesn't build the same lookup for $0 as it would outside of a regex [...] 02:09 < psch> that might easily be wrong though, but the fact that $/ is Match seems to hint at it... [...] 02:11 < psch> 'cause even if $/ isn't supposed to work there (which ISTR it isn't), at least $¢ should In case of bad editing refer to http://irclog.perlgeek.de/perl6/2015-12-20#i_11746338 and onward. The underlying issue seems to be that the special name $/ retains some kind of Match object when referenced inside any kind of code assertion inside of a regex, but accessing positional captures fails. I seem to recall mention of $/ not necessarily being valid in a regex, but trying to access $¢ instead is similarly fruitless.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org