Skip Menu |

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
Id: 82120
Status: stalled
Priority: 0/
Queue: Perl-Critic

Owner: Nobody in particular
Requestors: GWS [...]

Bug Information
Severity: Normal
Broken in: 1.118
Fixed in: (no value)

Subject: RegularExpressions::RequireExtendedFormatting: possibly false positive
Download (untitled) / with headers
text/plain 523b
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.
text/x-perl 759b
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;
Download (untitled) / with headers
text/plain 1.6k
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 is sponsored and maintained by Best Practical Solutions and runs on infrastructure.

Please report any issues with to