Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Perl-Critic CPAN distribution.

Report information
The Basics

Nobody in particular
GWS [...]

Broken in:
Fixed in:
(no value)

Subject: RegularExpressions::RequireExtendedFormatting: possibly false positive
The Perl::Critic core policy RegularExpressions::RequireExtendedFormatting reports a violation from line 22 of the source included, which reads return ( \%/, $^N ); This is not a regular expression at all. (It is the somewhat obscure way to reference the result of parsing with Regexp::Grammars.) As a further consequence, more violations are reported from the file (null statements, unreachable code). These all go away when removing the line named above. It seems the lexer of Perl::Critic gets confused by this code.
package ZVtest; use strict; use warnings; # Class variable: my $zv_grammar = do { use Regexp::Grammars 1.021; qr{ foo }xmsi }; sub new { my( $class ) = @_; my %params; my $self = bless( \%params, $class ); $params{_GRAMMAR} = $zv_grammar; $params{_ACTIONS} = ZVActions->new( foo => sub { return 'foo' } ); return $self; } sub compile { my( $self, $line ) = @_; return unless $line =~ $self->{_GRAMMAR}->with_actions( $self->{_ACTIONS} ); return ( \%/, $^N ); } 1; package ZVActions; sub new { my( $class ) = @_; my %params; return bless( \%params, $class ); } sub foo { my( $self ) = @_; my $foo = [ 'foo' // 42 ]; return; } sub bar { my( $self ) = @_; return; } 1;
Perl::Critic uses the PPI package to parse the file it is analyzing, and it appears that it's PPI that gets the parse wrong: $ ppidump 'return ( \%/, $^N );' PPI::Document PPI::Statement::Break [ 1, 1, 1 ] PPI::Token::Word 'return' PPI::Structure::List ( ... ??? PPI::Statement::Expression [ 1, 10, 10 ] PPI::Token::Cast '\' [ 1, 11, 11 ] PPI::Token::Operator '%' [ 1, 12, 12 ] PPI::Token::Regexp::Match '/, $^N );' I have not yet looked into how PPI decides whether it has a punctuation variable. Your problem suggests it knows about the ones in the Perl core, and if it sees something it does not recognize after the sigil it assumes it is not dealing with a variable at all. If we can get PPI fixed, Perl::Critic will get it right, but that's a big "if", given that, as I understand it, the author of PPI is not as completely immersed in Perl as he once was, so it may be hard to get a release, even assuming a patch can be worked out and submitted. In the meantime, a really ugly workaround would be to roll with the punches and change the failing line to something like return ( \%/, $^N ); # /smx ); The cascading problems are because PPI, having decided wrongly that it has found the beginning of a match operation, is looking for the end of same, gobbling up good code as it does. The workaround gives it something it will parse incorrectly as a match operation in parentheses, saving the rest of the parse, and (at least when I tried it) producing no warnings from core Perl::Critic policies. I'm going to mark this 'stalled', pending resolution of the PPI bug.
Thank you for the very fast analysis! And also für the clever workaround. \Gisbert

This service runs on Request Tracker, is sponsored by The Perl Foundation, and maintained by Best Practical Solutions.

Please report any issues with to