Skip Menu |

This queue is for tickets about the Regexp-Grammars CPAN distribution.

Report information
The Basics
Id: 120233
Status: open
Priority: 0/
Queue: Regexp-Grammars

People
Owner: Nobody in particular
Requestors: alexchandel [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: (no value)
Fixed in: (no value)



Subject: Using possessive lists doesn't save subrule results, causing mandatory result distillation
Writing a regex of the form, qr{ <program> <rule: program> <ladders> <rule: ladders> <[ladder]>++ <rule: ladder> etc... }xms; with a possessive list quantifier (in the "ladders" rule) causes the rule containing the possessive quantifier to return its context string at the end. From debugging, this seems to be because the "ladder" key, $MATCH{ladder}, in the "ladders" subrule is never created. If manual result distillation is attempted to force it to return the list, the value of $MATCH{ladder} is undefined.
Subject: Re: [rt.cpan.org #120233] Using possessive lists doesn't save subrule results, causing mandatory result distillation
Date: Tue, 14 Feb 2017 08:20:53 +1100
To: bug-Regexp-Grammars [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Hi Alex, Yes, this is a known issue with Regexp::Grammars (and arguably a bug in the Perl interpreter itself). It is addressed in the "LIMITATIONS" section of the documentation: Grammatical parsing with Regexp::Grammars can fail if your grammar places "non-backtracking" directives (i.e. the C<< (?>...) >> block or the C<?+>, C<*+>, or C<++> repetition specifiers) around a subrule call. The problem appears to be that preventing the regex from backtracking through the in-regex actions that Regexp::Grammars adds causes the module's internal stack to fall out of sync with the regex match. For the time being, you need to make sure that grammar rules don't appear inside a "non-backtracking" directive. Indeed, you should have received a compiler warning about possessive qualifiers not always working correctly, when you used one in a grammar. I have been unable to code around this bug within the parser-generator, so the current work-around is still to replace the ++ with a simple +. Damian