Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.7.2

Bug #18949 Call to private method from static
Submitted: 2011-10-30 23:16 UTC
From: finlay Assigned: squiz
Status: Closed Package: PHP_CodeSniffer (version 1.3.0)
PHP Version: 5.3.8 OS: Debian6
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 23 + 6 = ?

 
 [2011-10-30 23:16 UTC] finlay (Olivier Beaton)
Description: ------------ Trying to include a custom standard from another custom standard where neither have specific sniffs. Test bellow describes my situation. Looking at static method PHP_CodeSniffer::getSniffFiles() I see it calls private method PHP_CodeSniffer::_expandRulesetReference() -- could this be the problem? Test script: --------------- Project/GenericStandard/ ruleset.xml (includes a bunch of Generic. PEAR. etc stuff, has no sniffs of its own) Project/ProjectStandard/ ruleset.xml (includes GenericStandard, has no sniffs of its own) Soft links of both to /usr/share/php/PHP/CodeSniffer/Standard Ran phpcs through phing on my project, here are my options: <phpcodesniffer standard="OFB" allowedFileExtensions="php" docGenerator="HTML" docFile="docs/coding_standards.html" tabWidth="2" noSubdirectories="false"> <fileset refid="src"/> <formatter type="summary" usefile="false"/> <formatter type="full" outfile="reports/raw/codesniffer.errors.txt"/> <formatter type="xml" outfile="reports/raw/codesniffer.errors.xml"/> </phpcodesniffer> Got a a large amount of HTML outputted to the screen after the backtrace that looks to be the start of the docs/coding_standards.html file. Expected result: ---------------- a summary screen output (hapens) two output files and a .html coding standards file. Actual result: -------------- PHP Fatal error: Call to undefined method PHP_CodeSniffer_DocGenerators_HTML::getSniffFiles() in /usr/share/php/PHP/CodeSniffer.php on line 813 PHP Stack trace: PHP 1. {main}() /usr/share/php/phing.php:0 PHP 2. Phing::fire() /usr/share/php/phing.php:37 PHP 3. Phing::start() /usr/share/php/phing/Phing.php:270 PHP 4. Phing->runBuild() /usr/share/php/phing/Phing.php:170 PHP 5. Project->executeTargets() /usr/share/php/phing/Phing.php:564 PHP 6. Project->executeTarget() /usr/share/php/phing/Project.php:706 PHP 7. Target->performTasks() /usr/share/php/phing/Project.php:733 PHP 8. Target->main() /usr/share/php/phing/Target.php:300 PHP 9. Task->perform() /usr/share/php/phing/Target.php:277 PHP 10. PhpCodeSnifferTask->main() /usr/share/php/phing/Task.php:253 PHP 11. PHP_CodeSniffer->generateDocs() /usr/share/php/phing/tasks/ext/PhpCodeSnifferTask.php:422 PHP 12. PHP_CodeSniffer_DocGenerators_HTML->generate() /usr/share/php/PHP/CodeSniffer.php:1321 PHP 13. PHP_CodeSniffer_DocGenerators_Generator- >getStandardFiles() /usr/share/php/PHP/CodeSniffer/DocGenerators/HTML.php:50 PHP 14. PHP_CodeSniffer->getSniffFiles() /usr/share/php/PHP/CodeSniffer/DocGenerators/Generator.ph p:146 PHP 15. PHP_CodeSniffer->_expandRulesetReference() /usr/share/php/PHP/CodeSniffer.php:738

Comments

 [2011-10-30 23:24 UTC] finlay (Olivier Beaton)
oops, should I put there for my phing phpcs call standard="ProjectStandard" If I do: standard="GenericStandard" then everything works fine. The only thing in ProjectStandard is a <rule ref="GenericStandard"/>
 [2011-11-01 10:18 UTC] squiz (Greg Sherwood)
-Status: Open +Status: Feedback -Assigned To: +Assigned To: squiz
I think I've tracked down and fixed the problem with doc generation. I don't maintain or use the phing task, so I can't really test this very well. You can't generate docs at the same time as actually checking code, so I'm not sure what the phing task is doing, but the actions do work separately now. I've committed the fix to SVN. I'll leave this in Feedback to see if you are able to grab the SVN version and give it another try. If you can, please let me know how it goes.
 [2011-11-01 19:43 UTC] finlay (Olivier Beaton)
Fantastic. Thanks for the quick response. I've installed it and it's working no errors. Whatever you fixed did it! I was a bit confused about how to "get it from svn" and then install it, here's the steps I ended up doing: 1. Found the 'view source' link from the main CodeSniffer for ViewNC 2. Found the path to the actual svn repo from the php.net website. 3. Modified them to have the svn repo + codesniffer path to svn checkout. 4. I previously installed through pear, but that's the extent of my knowledge. I noticed a 'package.xml' file so I went out on a limb and guessed checked pear and typed 'pear package' while inside the directory, that gave me a tarball. 5. I then tried into install it with pear install <tarball> but it complained I was already up to date even though the tarball was 1.3.1 and I had 1.3.0 6. Uninstalled CodeSniffer and reinstalled using tarball 7. Tested and works! I hope I didn't mess up my pear install doing this, I want to get future CodeSniffer updates! I'm guessing that even though it labelled it 1.3.1 it is still considered 1.3.0, and will update automatically from the channel when that comes out.
 [2011-11-01 19:49 UTC] finlay (Olivier Beaton)
And just wanted to say, I think phpcs is a fantastic tool. So many things that would be a pain in the ass are now much easier and trivial to comply to. I especially like how you can make a sniff over the lifetime of a project for changes to your API, for your community. "use of X is deprecated, please use Y" and have different output for automated vs code review etc. My only gripe is that I haven't found an easy way to make relative paths work well (at least not with the phing task). A good model I imagine is to have a basic coding standard for all projects in your organization / individual. Then make a specific one for each project that inherits from the basic one, but adds for each specific project. While I can specify soft links in the standards directory to make it work, if I specify the path to my standard by hand, then all the uri's it uses for substandards have to be absolute, not relative. It would be great if I could specify additional search paths ontop of the "standard" directory to look for standards. If phpcs has this I'm sorry, and I'll submit it to phing.
 [2011-11-02 03:25 UTC] squiz (Greg Sherwood)
-Status: Feedback +Status: Closed
Thanks for getting back to me, and so quickly. I think there are a few requests regarding relative paths and I have made some progress on the command line, but not in the ruleset files. Fell free to suggest a few more to make your life easier.