Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the PPI CPAN distribution.

Report information
The Basics
Id: 13425
Status: resolved
Worked: 45 min
Priority: 0/
Queue: PPI

People
Owner: adamk [...] cpan.org
Requestors: johanl [...] cpan.org
Cc:
AdminCc:

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



Subject: bareword package erroneously identified as PPI::Statement::Package in hash key name
It seems like this: $p{package} is parsed as a PPI::Statement::Package instead of as a bareword string. I flagged this as a Normal bug, because it's possible for me to work around the behaviour like this: grep { $_->namespace } ... find package statements ... Test case: #!/usr/bin/perl -w use strict; use Data::Dumper; use Test::More tests => 5; use_ok("PPI"); use_ok("PPI::Document"); my $perl = q| sub main { print "sldkfjs"; } package Some::Package; sub oLocationSubDefinition { my %p = @_; my ($row, $package) = ($p{row}, $p{package}); if(! $package) { print "yup"; } return(undef); } |; ok(my $oDocument = PPI::Document->new(\$perl), "parse ok"); ok($oDocument->index_locations(), "index_locations ok"); my $raPackage = $oDocument->find("PPI::Statement::Package"); is(scalar(@$raPackage), 1, " found one package statement"); #print Dumper($raPackage); __END__ Bug: Note how the second line in my ($row, $package) = ($p{row}, $p{package}); is also identified as a Package statement when it's really a bareword string.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.