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

People
Owner: Nobody in particular
Requestors: jdeighan [...] pcgus.com
Cc:
AdminCc:

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



Subject: bug in Perl-Critic
Date: Tue, 14 Dec 2010 10:53:30 -0500
To: bug-Perl-Critic [...] rt.cpan.org
From: John Deighan <jdeighan [...] pcgus.com>
The following code (I've added line numbers): 1 # ---------------------------------------------------------- 2 3 use strict; 4 use warnings; 5 6 sub func { my($align) = @_; 7 8 my $hAttr = ($align eq 'center') ? { 'class' => 'treeroot', 9 'display' => 'table', 10 'left-margin' => 'auto', 11 'right-margin' => 'auto', 12 } 13 : ($align eq 'right') ? { 'class' => 'treeroot', 14 'display' => 'table', 15 'left-margin' => 0, 16 'right-margin' => 'auto', 17 } 18 : { 'class' => 'treeroot'}; 19 20 return $hAttr; 21 } # func() 22 23 # ---------------------------------------------------------- Results in the error: ---------------- C:\Scripts\test8.pl ---------------- Comma used to separate statements at line 8, column 38. See pages 68,71 of PBP. Comma used to separate statements at line 13, column 38. See pages 68,71 of PBP. -------------------------------------------------------------------------------- But, clearly, the commas are being used to separate keys and values in the definition of a hash. Here is some info about my setup: Perl-Critic: version 1.109 (I understand there's a 1.110, but it's not available via ppm) Perl: version 5.10.0 from ActiveState OS: Windows 2003 Server
On Tue Dec 14 10:53:57 2010, jdeighan@pcgus.com wrote: Show quoted text
> The following code (I've added line numbers): > > > 1 # ---------------------------------------------------------- > 2 > 3 use strict; > 4 use warnings; > 5 > 6 sub func { my($align) = @_; > 7 > 8 my $hAttr = ($align eq 'center') ? { 'class' => 'treeroot', > 9 'display' => 'table', > 10 'left-margin' => 'auto', > 11 'right-margin' => 'auto', > 12 } > 13 : ($align eq 'right') ? { 'class' => 'treeroot', > 14 'display' => 'table', > 15 'left-margin' => 0, > 16 'right-margin' => 'auto', > 17 } > 18 : { 'class' => 'treeroot'}; > 19 > 20 return $hAttr; > 21 } # func() > 22 > 23 # ---------------------------------------------------------- > > Results in the error: > > ---------------- C:\Scripts\test8.pl ---------------- > Comma used to separate statements at line 8, column 38. See pages > 68,71 of PBP. > Comma used to separate statements at line 13, column 38. See pages > 68,71 of PBP. >
-------------------------------------------------------------------------------- Show quoted text
> > But, clearly, the commas are being used to separate keys and values in > the definition of a hash. > > Here is some info about my setup: > > Perl-Critic: version 1.109 (I understand there's a 1.110, but it's not > available via ppm) > Perl: version 5.10.0 from ActiveState > OS: Windows 2003 Server
Unfortunately, this bug is not in Perl::Critic proper, but is inherited from PPI, which Perl::Critic uses to do its parsing, and which thinks that your hash constructors are blocks. Equally unfortunately, this has proven to be an especially recalcitrant bug (or collection of bugs, maybe), since the way Perl disambiguates hash constructors from blocks is undocumented. So it's hard to know how to fix this without breaking something else. Perl does, however, provide a mechanism (which PPI understands) for forcing interpretation of a set of curly brackets: a unary plus ('+{ ... }') forces a hash constructor, and a semicolon inside ('{; ... }') forces a block, as documented in perlref. It's a shame to have to change your code to get PPI and Perl::Critic to interpret it correctly, but that or a '## no critic' annotation are the only short-term solutions I know of. Maybe one of the other developers knows something. There's no Perl::Critic 1.110 on CPAN either. There's a 1.110_001 (in preparation for 1.111), but that shows the same behavior :-(