Skip to content

Conversation

@jrfnl
Copy link
Member

@jrfnl jrfnl commented Apr 11, 2022

New Tokens\TokenHelper class

As of PHPUnit 9.3, PHPUnit started using PHP-Parser as a basis to calculate code coverage.

The problem with this is that PHP-Parser backfills new PHP native tokens, while the code in this repo contains logic which checks for the existence of tokens using defined(). That logic breaks with PHP-Parser in play.

An external PHPCS standard may also be using PHP-Parser, but as Parser doesn't fix the tokenization of files, the tokens polyfilled by PHP-Parser would still cause interference.

To work round this, I'm introducing a TokenHelper::tokenExists() method which can distinguish tokens defined by PHP and PHPCS from tokens defined by PHP-Parser.

This should solve the issue in most cases, though in edge-cases, PHP-Parser could still prevent the PHPCS native Tokenizer\PHP class from providing polyfills when it should.

For external standards which want to use PHPUnit 9.3+ for calculating code coverage, warming the cache is also still recommended, though it shouldn't necessarily be needed anymore if the standard implements the use of the TokenHelper::tokenExists() method in all the appropriate places.

Includes unit tests.

Refs:

Note: while Helper would have been the more intuitive name for the class, as there is also a BackCompat\Helper class, this would mean use aliases would need to be used a lot, so instead, I've elected to name the class TokenHelper.

Implement use of the new TokenHelper::tokenExists() method

... in all the appropriate places.

jrfnl added 2 commits April 11, 2022 13:26
As of PHPUnit 9.3, PHPUnit started using PHP-Parser as a basis to calculate code coverage.

The problem with this is that PHP-Parser backfills new PHP native tokens, while the code in this repo contains logic which checks for the existence of tokens using `defined()`. That logic breaks with PHP-Parser in play.

An external PHPCS standard may also be using PHP-Parser, but as Parser doesn't fix the tokenization of files, the tokens polyfilled by PHP-Parser would still cause interference.

To work round this, I'm introducing a `TokenHelper::tokenExists()` method which can distinguish tokens defined by PHP and PHPCS from tokens defined by PHP-Parser.

This should solve the issue in most cases, though in edge-cases, PHP-Parser could still prevent the PHPCS native `Tokenizer\PHP` class from providing polyfills when it should.

For external standards which want to use PHPUnit 9.3+ for calculating code coverage, warming the cache is also still recommended, though it shouldn't necessarily be _needed_ anymore if the standard implements the use of the `TokenHelper::tokenExists()` method in all the appropriate places.

Includes unit tests.

Refs:
* sebastianbergmann/php-code-coverage#798
* https://github.com/nikic/PHP-Parser/blob/master/lib/PhpParser/Lexer.php

Note: while `Helper` would have been the more intuitive name for the class, as there is also a `BackCompat\Helper` class, this would mean use aliases would need to be used a lot, so instead, I've elected to name the class `TokenHelper`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

2 participants