Description: ------------ Similar to (now closed) bug #14077. Same backtrace, different way to trigger it. Note: I am running PHP 5.2.6 but this was not an option in the dropdown. Test script: --------------- <?php class mpgResponse{ var $term_id; var $currentTag; function characterHandler($parser,$data){ switch($this->currentTag) { case "term_id": { $this->term_id=$data; break; } } }//end characterHandler }//end class mpgResponse Expected result: ---------------- The list of detected coding standard violations in this file. Actual result: -------------- steve@steve-laptop:~/temp$ phpcs testcase.php Fatal error: Uncaught PHP_CodeSniffer_Exception: $stackPtr is not a class member var in /usr/share/php/PHP/CodeSniffer/Standards/PEAR/Sniffs/NamingConventions/ValidVariableNameSniff.php on line 51 #0 /usr/share/php/PHP/CodeSniffer/Standards/PEAR/Sniffs/NamingConventions/ValidVariableNameSniff.php(51): PHP_CodeSniffer_File->getMemberProperties(9) #1 /usr/share/php/PHP/CodeSniffer/Standards/AbstractVariableSniff.php(154): PEAR_Sniffs_NamingConventions_ValidVariableNameSniff->processMemberVar(Object(PHP_CodeSniffer_File), 9) #2 /usr/share/php/PHP/CodeSniffer/Standards/AbstractScopeSniff.php(190): PHP_CodeSniffer_Standards_AbstractVariableSniff->processTokenWithinScope(Object(PHP_CodeSniffer_File), 9, 1) #3 /usr/share/php/PHP/CodeSniffer/File.php(394): PHP_CodeSniffer_Standards_AbstractScopeSniff->process(Object(PHP_CodeSniffer_File), 9) #4 /usr/share/php/PHP/CodeSniffer.php(708): PHP_CodeSniffer_File->start(NULL) #5 /usr/share/php/PHP/CodeSniffer.php(335): PHP_CodeSniffer->processFile('/home/steve/tem...') #6 /usr/share/php/ in /usr/share/php/PHP/CodeSniffer/File.php on line 1883

The problem seems to be triggered by the use of { } inside the case statement. If you remove the curly brackets it won't throw an exception, fwiw.

The following patch has been added/updated: Patch Name: phpcs_bug_16071_fix.diff Revision: 1239978908 URL: http://pear.php.net/bugs/patch-display.php?bug=16071&patch=phpcs_bug_16071_fix.diff&revision=1239978908&display=1

The patch above is a pretty lame hack in that it duplicates the "ignore" functionality, but I couldn't find another way to keep ignores limited by "depth" (which seems to be the underlying problem) without running into a whole bunch of problems with failing tests that I didn't quite want to delve into. Hopefully the patch will help the maintainer easily identify the problem and perhaps develop a more elegant solution - or in the meantime, help those having this problem fix it. Despite its hackiness, it does fix this bug, and passes all existing unit tests.

More code to reproduce: <?php class Test { protected $_x = null; public function doSomething() { switch ($k) { case 1: { break; } } } }

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Just needed to reset the $ignore value back to it's original value if we completed our task but returned a value that made the tokenizer head back over the same code again. This only happened with shared openers (like for CASE statements using the same : char) and caused the tokenizer to see the ignored token twice.