Proposal: treat deprecations/notices/warnings coming from sniffs in a more end-user friendly manner

[jrfnl]

Current situation

As things currently are, when a PHP deprecation/notice/warning/error is received during the scanning of a file, PHPCS turns this into an Internal.Exception and kills the scan of that particular file.

Example 1:

• A file containing 200 lines of code contains a parse error on line 100.
• One of the sniffs involved in the scan does not contain enough defensive coding, which leads to a PHP notice for the code on line 100.
• PHPCS will report the notice as an Internal.exception on line 1 of the file.
• PHPCS will show the scan results for line 1 - 99 of the file.
• No errors or warnings are reported for line 100 - 200 of the file.

Example 2:

• PHP makes a change which causes a deprecation notice in a pre-existing sniff.
• One of the files being scanned causes the sniff to hit the deprecation notice.
• PHPCS will report the notice as an Internal.exception on line 1 of the file.
• PHPCS will show the scan results for the file up to the point the code hit the deprecation notice.
• No errors or warnings are reported for the rest of the file.

The problem

While it is important for sniff authors to have access to this information (to allow them to fix the sniff), this is not user-friendly for end-users who cannot do anything with that information, other than report it to the relevant standard and in the mean time, their code is not fully scanned.

So... I'm wondering if we cannot find a way to make this more user-friendly for end-users, while still keeping the information available for sniff authors.

Important caveat: while the scan results for the "rest of the file" will be fine for PHP deprecations/notices/warnings caused by a logic oversight in the sniff or a change in PHP, if the file being scanned contains a parse error, chances are high that the scan results for the "rest of the file" are unreliable (at best) or even complete nonsense (at worst).

Proposal

I haven't thought this through completely yet, but these are some thoughts I have around this which I'm sharing to receive feedback on them.

Rough outline of proposal:

• Leave the existing behaviour in place for fatal errors.
• Collect all deprecations/notices/warnings seen during the scan, but don't abort scanning a file on those.
• Report the number of deprecations/notices/warnings encountered during a scan at the bottom of the output and exit with 1 if any were seen (same as before as previously the Internal.Exception would cause an exit code of 1).
• Report the full details of deprecations/notices/warnings encountered during a scan at the bottom of the output when running with -v and exit with 1 if any were seen (same as before).
• Add a new CLI argument --ignore-php-notices (or something along those lines) to allow the exit code to be 0 if there were deprecations/notices/warnings.
• In PHPCS 4.0.0, reverse the behaviour for the exit code, meaning PHP deprecations/notices/warnings will no longer cause an exit code of 1, but will exit with 0 instead. Replace the --ignore-php-notices CLI argument with a --fail-on-php-notices CLI argument to still get a 1 exit code when there are notices.

We also may need to make some accommodation in the test framework to allow test runs to still always report those deprecations/notices/warnings and fail a test run if any are encountered.

Thoughts ?

[jrfnl]

Related #2871

[jrfnl]

Closing as replaced by PHPCSStandards/PHP_CodeSniffer#30