Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rakudo (nqp-rx) regexes won't backtrack properly into capturing parentheses or subrules #1606

Closed
p6rt opened this issue Mar 17, 2010 · 7 comments
Labels

Comments

@p6rt
Copy link

p6rt commented Mar 17, 2010

Migrated from rt.perl.org#73608 (status was 'resolved')

Searchable as RT73608$

@p6rt
Copy link
Author

p6rt commented Mar 17, 2010

From @masak

<masak> rakudo​: say "aaaab" ~~ /a*b/; say "aaaab" ~~ /.*b/; say
"aaaab" ~~ /(a*)b/; say "aaaab" ~~ /(.*)b/
<p6eval> rakudo e3937f​: OUTPUT«aaaab␤aaaab␤aaaab␤␤»
* masak submits rakudobug
<masak> oh, and bug courtesy of jnthn++

Just to be extra clear, all four of the above should print 'aaaab'
(followed by a newline), but the combination of a backtracking
construct such as quantifier​:sym<*> and capturing parens doesn't work.

And it's not specific for the quantifiers, either. This should print 'ab'​:

<masak> rakudo​: say "ab" ~~ / (ab|a) b /
<p6eval> rakudo e3937f​: OUTPUT«␤»

So there's something wrong with backtracking and capturing in general.

This is really a bug in nqp-rx, but I'm submitting it as a rakudobug.

@p6rt
Copy link
Author

p6rt commented Apr 25, 2010

From @masak

<masak> rakudo​: grammar G { regex TOP { <foo> a }; regex foo { a* } }; say ?G.parse("aaa")
<p6eval> rakudo e393c7​: OUTPUT«0␤»
<masak> alpha​: grammar G { regex TOP { <foo> a }; regex foo { a* } }; say ?G.parse("aaa")
<p6eval> alpha 30e0ed​: ( no output )
<masak> locally, alpha gives me '1', which is the correct answer.
* moritz_ agrees
<masak> there's https://rt-archive.perl.org/perl6/Ticket/Display.html?id=73608 in RT already.
<masak> this one is clearly related; is it identical, or should I submit a new one for this one?
<masak> capturing parens and subrules are related but not identical.
<masak> (and given that the former doesn't work, I'm not surprised that the latter doesn't,
either)
<masak> though I *am* surprised that the Perl 6 grammar in Rakudo doesn't suffer more
from these bugs.
<moritz_> masak​: it mostly uses tokens anyway
<masak> right. not much backtracking going on in the first place.

@p6rt
Copy link
Author

p6rt commented Apr 25, 2010

From [Unknown Contact. See original ticket]

<masak> rakudo​: grammar G { regex TOP { <foo> a }; regex foo { a* } }; say ?G.parse("aaa")
<p6eval> rakudo e393c7​: OUTPUT«0␤»
<masak> alpha​: grammar G { regex TOP { <foo> a }; regex foo { a* } }; say ?G.parse("aaa")
<p6eval> alpha 30e0ed​: ( no output )
<masak> locally, alpha gives me '1', which is the correct answer.
* moritz_ agrees
<masak> there's https://rt-archive.perl.org/perl6/Ticket/Display.html?id=73608 in RT already.
<masak> this one is clearly related; is it identical, or should I submit a new one for this one?
<masak> capturing parens and subrules are related but not identical.
<masak> (and given that the former doesn't work, I'm not surprised that the latter doesn't,
either)
<masak> though I *am* surprised that the Perl 6 grammar in Rakudo doesn't suffer more
from these bugs.
<moritz_> masak​: it mostly uses tokens anyway
<masak> right. not much backtracking going on in the first place.

@p6rt
Copy link
Author

p6rt commented Apr 25, 2010

@masak - Status changed from 'new' to 'open'

@p6rt
Copy link
Author

p6rt commented Jul 19, 2010

From @pmichaud

Now fixed in 9005478​:

  pmichaud@​plum​:~/rakudo$ ./perl6
  > say "aaaab" ~~ /(.*)b/;
  aaaab
  > say "ab" ~~ / (ab|a) b /;
  ab
  > grammar G { regex TOP { <foo> a }; regex foo { a* } }; say
?G.parse("aaa");
  1
  >

Pm

@p6rt
Copy link
Author

p6rt commented Jul 19, 2010

From @moritz

I've just unfudged a few tests for that in S05-mass/recursive.t, so I
don't see any reason to keep the ticket open any longer.

@p6rt
Copy link
Author

p6rt commented Jul 19, 2010

@moritz - Status changed from 'open' to 'resolved'

@p6rt p6rt closed this as completed Jul 19, 2010
@p6rt p6rt added the Bug label Jan 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant