Tokens: fix up some PHPCS native token values #3218
Conversation
The PHPCS native token types are normally prefixed with `PHPCS_`. This wasn't the case for the most recent three additions, `T_FN_ARROW` as introduced in PHPCS 3.5.3, `T_TYPE_UNION` and `T_PARAM_NAME` as will be introduced in PHPCS 3.6.0 (not yet released). While the change to the value for `T_FN_ARROW` could be considered a breaking change, it is exceedingly rare for a sniff to use the _value_ of a token constant, so IMO opinion, this is a safe change to make. As for the other two tokens, as they have not been in a release yet, they can be safely updated no matter what.
|
@gsherwood I think this one should definitely go into 3.6.0. Would you mind milestoning it ? |
|
Well spotted, thanks for fixing those. Agree that nobody should actually be looking at the value. They are only prefixed like that because PHPUnit (I think) introduced the same tokens with different values at some point in the past and they conflicted with all the existing PHPCS ones, so it was for library compatibility more than anything else. |
|
Makes sense and all the more relevant now PHPUnit has started using PHP_Parser since PHPUnit 9.3 for code coverage. I already ran into breakage in an external library (PHPCompatibility) caused by PHP_Parser backfilling tokens while the sniff was relying on detecting the combination of PHP/PHPCS by checking Reason I noticed it now was, that I was getting some weird token names ( |
The values of the PHPCS native token types are normally prefixed with
PHPCS_. This wasn't the case for the three most recent additions,T_FN_ARROWas introduced in PHPCS 3.5.3,T_TYPE_UNIONandT_PARAM_NAMEas will be introduced in PHPCS 3.6.0 (not yet released).While the change to the value for
T_FN_ARROWcould be considered a breaking change, it is exceedingly rare for a sniff to use the value of a token constant, so IMO opinion, this is a safe change to make.As for the other two tokens, as they have not been in a release yet, they can be safely updated no matter what.