The constant "T_BAD_CHARACTER" is removed since PHP 7.0

[harikagujjula]

Bug Description

Running PHP compatibility check is resulting in the following errors with PHP 8.1.

nikic/php-parser/lib/PhpParser/Lexer.php

46 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0
109 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0
151 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0

This is supposedly added back in PHP 7.4.
Reference: nikic/PHP-Parser#701 (comment)

Given the following reproduction Scenario

Running PHPCS command on https://github.com/nikic/PHP-Parser/releases/tag/v4.15.1 is resulting an error.

The issue happens when running this command:

phpcs -p vendor/nikic --standard=PHPCompatibility --runtime-set testVersion 8.1

... over a file "nikic/php-parser/lib/PhpParser/Lexer.php".

... with this custom ruleset:
phpcs - 3.7.1, phpcompatibility - 9.3.5 (latest versions available).

Instead this happened

46 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0
109 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0
151 | ERROR | The constant "T_BAD_CHARACTER" is removed since PHP 7.0

Environment

Environment	Answer
PHP version	8.1
PHP_CodeSniffer version	3.7.1
PHPCompatibility version	9.3.5
Install type	Composer project local

Tested Against develop branch?

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

[ushmagupta]

any fix yet ?

[fredden]

From what I can tell, T_BAD_CHARACTER was removed in php/php-src@e9f99e3 (PHP 7.0.0) and re-added in php/php-src@9ad094e (PHP 7.4.0).

[kevin-j-morse]

I believe the only way to fix this is to remove T_BAD_CHARACTER from the list of constants being searched for in RemovedConstantsSniff.php

This is because the $removedConstants array only takes the first PHP version where the constant was removed and then incorrectly assumes it is still removed for all later PHP versions.

T_BAD_CHARACTER is an unusual case because it was removed in 7.0 and then re-added in 7.4

This would have the side effect of not properly alerting users of PHP 7.0, 7.1, 7.2, and 7.3 if they happened to be using this removed constant but given that those versions have been EOL for several years now I think this is the correct approach.

[jrfnl]

@kevin-j-morse No, the constant needs to be special cased in both the RemovedConstants as well as the NewConstants sniff.

[kevin-j-morse]

@jrfnl is there any documentation on how this special casing works?

I looked through the other constants and I couldn't see any other examples where this is the case.

[jrfnl]

@kevin-j-morse Correct. It's never been needed before (no PHP constant has ever been removed and then re-added other than this one), so the special casing is a new feature which will need to be build into the sniffs (which is also why this hasn't been actioned (yet) as it's not so straight forward as just adding to one of the lists).