Giters

PHPCompatibility / PHPCompatibility

PHP Compatibility check for PHP_CodeSniffer

Home Page:http://techblog.wimgodden.be/tag/codesniffer/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

phpcbf doesn't fix issues found by phpcs

tomekpolska opened this issue · comments

commented

Bug Description

phpcbf doesn't fix issues found with phpcs

Given the following reproduction Scenario

The issue happens when running this command:

./vendor/bin/phpcbf -p

Produces the output:

...............S.S...S....S..S..S.......S.S.................  60 / 114 (53%)
......................................................       114 / 114 (100%)

No fixable errors were found

... with this custom ruleset:

<?xml version="1.0"?>
<ruleset name="Custom Standard UDT" namespace="UDT\Portal">
    <config name="installed_paths" value="vendor/phpcompatibility/php-compatibility"/>
    <config name="standard" value="PHPCompatibility"/>
    <config name="testVersion" value="7.4"/>
    <file>./</file>
    <rule ref="PHPCompatibility"/>
</ruleset>

While

 ./vendor/bin/phpcs -p --report=source

Reports some issues:

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
--------------------------------------------------------------------------------------
STANDARD  CATEGORY            SNIFF                                              COUNT
--------------------------------------------------------------------------------------
Internal                      Tokenizer                                          8
PHPCompa  Function use        Removed functions ociparse deprecated              5
PHPCompa  Function use        Removed functions ocifreestatement deprecated      4
PHPCompa  Extensions          Removed extensions oracle removed                  1
PHPCompa  Function use        Removed functions ocirowcount deprecated           1
PHPCompa  Variables           New uniform variable syntax found                  1
--------------------------------------------------------------------------------------
A TOTAL OF 20 SNIFF VIOLATIONS WERE FOUND IN 6 SOURCES
--------------------------------------------------------------------------------------

I'd expect the following behaviour

Fix the issues found by phpcs with the same ruleset.

Environment

Environment Answer
PHP version 7.1
PHP_CodeSniffer version 3.7.1
PHPCompatibility version 9.3
Install type Composer project local

Additional Context (optional)

./vendor/bin/phpcs -i
The installed coding standards are MySource, PEAR, PSR1, PSR2, PSR12, Squiz, Zend and PHPCompatibility

Tested Against develop branch?

  • I have verified the issue still exists in the develop branch of PHPCompatibility.
commented

@tomekpolska This is exactly right and as it should be. Aside from a few minor syntax changes, there is no "one fix" which can always be applied.
Issues flagged by PHPCompatibility will in nearly all cases need the attention of a developer to decide how to fix something. Fixes can involve lots of different changes: change the syntax, rename a function and all uses of the old function, add a polyfill, add a parameter and decide what the value should be etc - and often need changes in multiple places/files, which is something PHPCS cannot do.

Take for example the issues flagged in your example above: the oracle extension is removed - how is PHPCompatibility to know how you want to solve this ?
First off, you may not even be using the oracle extension and this may be a false positive for a function which is "squatting" on the oracle prefix which is reserved by PHP for that extension.
If it is not a false positive, it could be solved in all sorts of manners, i.e.: add a PECL extension, switch to a different database system, if so, which ?, polyfill the extension etc etc.
This is not something PHPCompatibility can decide - or fix - for you.

So sorry, but aside from some very simple exceptions, like the PHP 7.4 deprecation/PHP 8.0 removal of the curly brace array access syntax, adding auto-fixers to PHPCompatibility would actually be dangerous and more often than not lead to broken code.

Note: for those simple exceptions, PRs to add an auto-fixer would be judged on their merit and if they have merit, those PRs would be accepted, but that only applies to a very very very small number of the sniffs.

On a completely different note; I'd be very interested to see the code which is causing the Internal.Tokenizer errors as that is something which need addressing in PHPCS itself.

commented

@jrfnl Thank you for the explanation. That means I need another tool to fix such simple exceptions like deprecations - I have plenty of them in my legacy code. Some suggestions would be appreciated.

How can I find the files causing Internal.Tokenizer errors? They are not listed with --report=full only with --report=source.

commented

@jrfnl Thank you for the explanation. That means I need another tool to fix such simple exceptions like deprecations - I have plenty of them in my legacy code. Some suggestions would be appreciated.

Well, the PHP 7.4 deprecation/PHP 8.0 removal of the curly brace array access can be auto-fixed by PHPCompatibility and as I said before, I'm not adverse to adding more auto-fixers when the fix is non-controversial.

Other than that and if your code doesn't need to stay cross-version compatible, you could have a look at Rector as a tool for upgrading code.

How can I find the files causing Internal.Tokenizer errors? They are not listed with --report=full only with --report=source.

They should actually also show with --report=full, but will normally be listed on line 1, even though the problem is elsewhere in the file.

Is the code you are scanning public ? If so, I could have a look. If not.... it's not always easy to determine what is breaking the tokenizer.

If you know the file which contains the code triggering the Tokenizer error and the file doesn't contain any parse errors (against the PHP version on which you are running PHPCS), I would normally try to "bisect" the file to find the problem code if it's not obvious from the error file/line info.
What I mean by that, is; remove the bottom half of the code in the file: see if the error still occurs. If not, bring back the bottom half of the code and remove the top half. Then confirm the error shows up again. Then for the remaining code, keep doing the same - remove half the code to determine if the error is in the top or the bottom half - until you've isolated a small enough code sample with which to reproduce the error.

I realize it's a pain to do this, but if there is a tokenizer error, the scan results for the file will be incomplete, so we're better off fixing the error ...

commented

Finally I used Rector to fix the issues, thanks.

Back to Tokenizer error. It was caused by minified js/css files. The errors gone when I specified --extensions=php for phpcs command line.

FILE: /DataTables/media/js/jquery.dataTables.min.js
---------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
---------------------------------------------------------------------------------------------------------------------
 1 | WARNING | File appears to be minified and cannot be processed
---------------------------------------------------------------------------------------------------------------------
commented

@tomekpolska Ah, that makes total sense. Thank you for checking this.

I presume we can now close this issue ?

commented

Yes, we can. Thank you once again.