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: 65663
Status: resolved
Priority: 0/
Queue: Perl-Critic

People
Owner: Nobody in particular
Requestors: user42 [...] zip.com.au
Cc:
AdminCc:

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



Subject: RequireConsistentNewlines five-part PPI location
Date: Sat, 12 Feb 2011 11:35:55 +1100
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
RequireConsistentNewlines mangles a $token->{_location} to force a line/column position for its violation. I believe recent PPI has a five element array there rather than three. I struck this when using '%f' logical filename in an output format, which got undef from the RequireConsistentNewlines location. Except it didn't want to go bad in 1.111, only the current svn, so I hope I haven't made a mess myself, but it does look like it should be a 5 not 3. I expect this is another policy which wants to report a violation position at an offset position into an element (the toplevel document in this case), when that can be done, $self->violation( $DESC, $EXPL, $document, line_number => $line, column_number => $col);
Index: RequireConsistentNewlines.pm =================================================================== --- RequireConsistentNewlines.pm (revision 4038) +++ RequireConsistentNewlines.pm (working copy) @@ -57,7 +57,9 @@ $newline ||= $nl; if ( $nl ne $newline ) { my $token = PPI::Token::Whitespace->new( $nl ); - $token->{_location} = [$line, $col, $col]; + $token->{_location} = [$line, $col, $col, + $line, # logical line + $filename]; # logical filename push @v, $self->violation( $DESC, $EXPL, $token ); } $line++;
On Fri Feb 11 19:36:02 2011, user42@zip.com.au wrote: Show quoted text
> RequireConsistentNewlines mangles a $token->{_location} to force a > line/column position for its violation. I believe recent PPI has a five > element array there rather than three. > > I struck this when using '%f' logical filename in an output format, > which got undef from the RequireConsistentNewlines location. Except it > didn't want to go bad in 1.111, only the current svn, so I hope I > haven't made a mess myself, but it does look like it should be a 5 > not 3. > > I expect this is another policy which wants to report a violation > position at an offset position into an element (the toplevel document in > this case), when that can be done, > > $self->violation( $DESC, $EXPL, $document, > line_number => $line, > column_number => $col); > > >
Thank you. There is work to address this issue being done on a branch, but it probably won't make it into Perl::Critic for the next release, so we'll just have to stick with the encapsulation violation.
My previous comment was dashed off rather hastily, and is much less clear than it ought to have been. The problem is that this policy bypasses PPI to have access to the _real_ line endings, but Perl::Critic needs a PPI::Element to build a violation around. The policy dealt with this, basically, by manufacturing its own PPI::Element and then violating encapsulation. Incorrectly, as you point out. This probably didn't matter until people got serious about handling the #line and #file directives. But now violations seem to be really noisy, even if you are not using %f. A fix is committed as SVN revision 4039. This is basically the same as your suggested patch, and compounds the felony, but at the moment there appears to be no better way to proceed. There is work on a branch that, if it ever makes it into the trunk, should give a way to report violations relative to the start of the element under analysis. That would let us get rid of the encapsulation violation. But we're trying to get a production version out shortly, so changes as large as the branched code are not really up for inclusion. Maybe that's clearer.
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Mon, 14 Feb 2011 20:04:16 -0600
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
I don't think that the stuff released in 1.113 is any worse than what was there before. Barring PPI properly keeping track of newlines, the only full solution that I can think of would be for the Policy to count newlines in Elements and figure out which Element to use based upon that. (Anyone think dealing with PPI::Token::HereDoc would be fun?)
On Mon Feb 14 21:04:29 2011, clonezone wrote: Show quoted text
> I don't think that the stuff released in 1.113 is any worse than what > was there before. Barring PPI properly keeping track of newlines, > the only full solution that I can think of would be for the Policy > to count newlines in Elements and figure out which Element to use > based upon that. (Anyone think dealing with PPI::Token::HereDoc > would be fun?)
The stuff in the aforementioned branch was supposed to provide a by-name interface to P::C::Policy->violation(). The reason that was desirable was because a PPI::Token::Pod is just a big hunk of text, and a by-name interface would allow the violation subsystem to be enhanced to allow an optional line offset into the element. There are a couple tickets that this would address. Given this, RequireConsistentNewlines would still have to grovel through the raw text counting lines, but having found a problem it could just report a violation on the document object, telling the interface how far into the document things are, and the violation would have a meaningful line number without having to hammer data into a from-scratch PPI::Element.
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Tue, 15 Feb 2011 06:16:24 -0600
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
On 2/14/11 9:18 PM, Tom Wyant via RT wrote: Show quoted text
> Given this, RequireConsistentNewlines would still have to grovel through > the raw text counting lines, but having found a problem it could just > report a violation on the document object, telling the interface how far > into the document things are, and the violation would have a meaningful > line number without having to hammer data into a from-scratch PPI::Element.
While this might help in finding the location of an error, it actually causes a problem with making clear where a single-line "## no critic" should go.
On Tue Feb 15 07:16:43 2011, clonezone wrote: Show quoted text
> On 2/14/11 9:18 PM, Tom Wyant via RT wrote:
> > Given this, RequireConsistentNewlines would still have to grovel
> through
> > the raw text counting lines, but having found a problem it could
> just
> > report a violation on the document object, telling the interface how
> far
> > into the document things are, and the violation would have a
> meaningful
> > line number without having to hammer data into a from-scratch
> PPI::Element. > > While this might help in finding the location of an error, it actually > causes a problem with making clear where a single-line "## no critic" > should go.
Are we not interested in telling people where errors are? I can see your point if we're stupid about reporting, but where we really need to give a more-specific location is in some of the Pod policies -- that's where the RT tickets are. And you can't annotate Pod anyway, so as I see it it's no less clear where the '## no critic' goes than it ever was. And in the case of RequireConsistentNewlines there is no contemplated change in what we report, just an opportunity to not violate encapsulation. Put another way: do you have an actual example where reporting the actual location of an error in a block of Pod makes it harder to tell where to put a '## no critic' annotation?
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Tue, 15 Feb 2011 19:32:22 -0600
To: bug-Perl-Critic [...] rt.cpan.org
From: Elliot Shank <perl [...] galumph.com>
On 2/15/11 9:52 AM, Tom Wyant via RT wrote: Show quoted text
> Put another way: do you have an actual example where reporting the > actual location of an error in a block of Pod makes it harder to tell > where to put a '## no critic' annotation?
I'm just worried about the disconnect.
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Thu, 17 Feb 2011 09:52:31 +1100
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Tom Wyant via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
> > The problem is that this policy bypasses PPI to have access to the > _real_ line endings
Could it ask Perl::Critic::Document nicely for the original input? Show quoted text
> Perl::Critic needs a PPI::Element to build a violation around
The toplevel document presumably, when a linenum offset can be given. Show quoted text
> violating encapsulation. Incorrectly
Well, to the extent of not knowing the extra info in newer ppi. Show quoted text
> #line and #file directives
I suppose the violation constructor bit would take a raw line num offset and work out the logical line -- including ignoring #line within here-documents no doubt.
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Thu, 17 Feb 2011 09:56:40 +1100
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Tom Wyant via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
> > by-name interface to P::C::Policy->violation()
It's just some extra by-name args? Only a few violations want to report a position within an element, the majority would be unchanged.
Subject: Re: [rt.cpan.org #65663] RequireConsistentNewlines five-part PPI location
Date: Thu, 17 Feb 2011 10:04:16 +1100
To: bug-Perl-Critic [...] rt.cpan.org
From: Kevin Ryde <user42 [...] zip.com.au>
"Tom Wyant via RT" <bug-Perl-Critic@rt.cpan.org> writes: Show quoted text
> > you can't annotate Pod > anyway, so as I see it it's no less clear where the '## no critic' goes > than it ever was.
Straying off-topic, but for interest in my ProhibitVerbatimMarkup I made an =for ProhibitVerbatimMarkup allow next which doesn't look fantastic, but does per-paragraph control. Maybe something like block-ish like =for Perl_Critic no (ProhibitSomething) ... =for Perl_Critic use (ProhibitSomething)