Description: ------------ If I run CodeSniffer on a particular file, I get a certain number of errors. If I include a certain second file in the run, I get a different number of errors for the first file. The best way I can explain this is to illustrate: $ phpcs file_b.php FILE: file_b.php -------------------------------------------------------------------------------- FOUND 5 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S) -------------------------------------------------------------------------------- 2 | ERROR | You must use "/**" style comments for a file comment 84 | ERROR | Expected "if (...) {\n"; found "if(...)\n{\n" 86 | ERROR | Line indented incorrectly; expected at least 4 spaces, found 1 <snip> -------------------------------------------------------------------------------- $ phpcs file_a.php file_b.php FILE: file_a.php -------------------------------------------------------------------------------- FOUND 60 ERROR(S) AND 0 WARNING(S) AFFECTING 60 LINE(S) -------------------------------------------------------------------------------- <snip> -------------------------------------------------------------------------------- FILE: file_b.php -------------------------------------------------------------------------------- FOUND 4 ERROR(S) AND 0 WARNING(S) AFFECTING 4 LINE(S) -------------------------------------------------------------------------------- 2 | ERROR | You must use "/**" style comments for a file comment 86 | ERROR | Line indented incorrectly; expected at least 4 spaces, found 1 <snip> -------------------------------------------------------------------------------- Notice that the inclusion of file_a.php seems to be affecting the number of errors reported for file_b.php - line 84 is not caught on the second run. This only manifests if I specify file_a.php before file_b.php on the command line. This only happens with certain combinations of files, and I haven't been able to find a pattern. I've been playing around with the contents of the files. It seems to have something to do with the number of tokens in the file - if I delete too many tokens, the problem goes away. However, I can swap out tokens for the same number of different tokens (even comment lines) and the problem still occurs. There is a block of inline HTML with JavaScript in the middle of each of the files, and the length of this block seems to affect it somehow - if I shorten enough of the JS variable names, the problem goes away. If you need more information, ask and I can provide files that reproduce the problem (I would need to spend a little time cleaning them up first so I am not sharing my employer's proprietary code).

Thank you for taking the time to report a problem with the package. This problem may have been already fixed by a previous change that is in the CVS of the package. Please log into CVS with: cvs -d :pserver:cvsread@cvs.php.net:/repository login and check out the CVS repository of this package and upgrade cvs -d :pserver:cvsread@cvs.php.net:/repository co pear/PHP_CodeSniffer pear upgrade pear/PHP_CodeSniffer/package2.xml or pear upgrade pear/PHP_CodeSniffer/package.xml If you are able to reproduce the bug with the latest CVS, please change the status back to "Open". Again, thank you for your continued support of PEAR. I'm pretty sure this is already fixed in SVN.

And of course, those instructions are not correct any more. To grab the SVN version (need to remove first as some files are deleted and version is the same) pear uninstall PHP_CodeSniffer svn co http://svn.php.net/repository/pear/packages/PHP_CodeSniffer/trunk PHP_CodeSniffer cd PHP_Codesniffer pear install package.xml

I just tried it with the latest trunk checkout, and the described behavior still occurs. The numbers given in the "FOUND X ERROR(S)" message have changed and seem to accurately reflect the number of error entries now, but that error at line 84 is still only caught when running against the single file.

I have not seen an error like this before, so I don't think I can replicate it without your sample code. If you could get me those files, I'd be very grateful. I suspect a sniff is not cleaning up after itself and so still has the first file's content in there somewhere, but I still haven't come across it in any tests or in full runs over large codes bases, so I'm not sure where the error is exactly.

Added patch testcase_file_a.php.txt.

Added patch testcase_file_b.php.txt.

Added two files that reproduce this behavior (I added them as patches because that was the only way I could find to upload). You'll need to remove the backslash on the first line of each of them.

You're a legend. These files replicate the problem perfectly. Thanks a lot.

I think I've found it now. Try the latest SVN version again.

Excellent, that seems to have solved the problem. Tried it on the larger files where I initially encountered issues and those look to be working better as well. Thanks!

Good news. Thanks for testing.