| Subject: | fatal error critiquing perl 5.10 regexp |
| Date: | Sat, 05 Sep 2009 08:03:10 +1000 |
| To: | bug-Perl-Critic [...] rt.cpan.org |
| From: | Kevin Ryde <user42 [...] zip.com.au> |
With the current cvs and two files foo.pl and bar.pl both containing
$x =~ /^([a-z])++/
running
perlcritic foo.pl bar.pl
gets a fatal error on foo.pl
Fatal error while critiquing "foo.pl": Nested quantifiers; marked by <-- HERE in m/^([a-z])++ <-- HERE / at /usr/share/perl5/Regexp/Parser/Objects.pm line 719
and doesn't go on to critique bar.pl, whereas I hoped that a perl 5.10
regexp like in foo.pl wouldn't prevent bar.pl from being processed, and
preferrably wouldn't prevent other aspects of foo.pl being processed
either.
I suspect Regexp::Parser 0.20 doesn't fully determine its errors when
the string is set in, but instead croaks in later operations, which
perlcritic takes to be an un-continuable error (probably reasonable).
I get some joy from protecting per below.
Index: PPIRegexp.pm
===================================================================
--- PPIRegexp.pm (revision 3613)
+++ PPIRegexp.pm (working copy)
@@ -61,6 +61,15 @@
return if ! $parser->regex($re);
}
+ # The docs of Regexp::Parser 0.20 seem to say its errors and warnings are
+ # determined at the ->regexp stage, but some perl 5.10 forms like
+ # /^([a-z])++/ cause a croak() at the subsequent ->parse stage. Dunno if
+ # it's the code or docs which are right or wrong, but as a workaround
+ # parse now instead of dying later in one of the methods which depend on
+ # the parse being done, like $parser->captures or whatnot.
+ #
+ return unless eval { $parser->parse; 1 };
+
return $parser;
}