-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Support for PHP 8.1 Explicit Octal Notation in the Tokenizer #3481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for PHP 8.1 Explicit Octal Notation in the Tokenizer #3481
Conversation
…o777") from two separate T_NUMBER and T_STRING tokens into a single T_NUMBER token with the correct value
…ence (e.g."0o777") from two separate T_NUMBER and T_STRING tokens into a single T_NUMBER token with the correct value
…ill works correctly with Explicit octal values when they have to be backfilled
| { | ||
| $tokens = self::$phpcsFile->getTokens(); | ||
|
|
||
| $number = $this->getTargetToken($testData['marker'], [T_LNUMBER, T_DNUMBER, T_STRING]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we only looking for T_LNUMBER tokens here or are there test cases to add where T_DNUMBER and T_STRING would be valid to find? Might need some tests to ensure some strings that look octal are not actually being touched ?
| <?php | ||
|
|
||
| /* testExplicitOctal declaration */ | ||
| $foo = 0o137041; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again: what about a number with uppercase o ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also wondering if any test could be conceived where the token stream should not be changed (i.e. guard against false positives).
Check for lower- or upper-case 'o'. Don't adjust $token and $tokens variables; but set the token in $finalTokens, and adjust pointers.
|
Thanks a lot for the contribution and for making those requested changes. I made a couple of minor changes to the tests but didn't add anything about a case where the token should not be changed (can't think of a case off the top of my head). If anyone has any, please post here and I'll add the test case in. |
This add support for the explicit octal notation using a `0o`/`0O` prefix as supported in PHP as of PHP 8.1. The only method which needed adjusting was the `Numbers::getCompleteNumber()` method, which now backfills the tokenization when needed. For the `Numbers::isOctalInt()` method, a small tweak to the regex was all that was needed. As for the `Numbers::getDecimalValue()` method: this already handled the conversion correctly due to the use of the PHP native `octdec()` function. From the RFC: > Surprisingly PHP already has support for this notation when using the `octdec()` and `base_convert()` functions. Includes adding unit tests to safeguard support in all relevant methods in the class. Refs: * https://wiki.php.net/rfc/explicit_octal_notation * php/php-src#6360 * squizlabs/PHP_CodeSniffer#3481 * squizlabs/PHP_CodeSniffer#3552
Added support for Explicit Octal Notation (introduced in PHP 8.1) in the tokenizer.
When running phpcs against PHP < 8.1, an expression like
separates the
0o777into two tokens; aT_LNUMBERwith a value"0"and aT_STRINGwith a value"o777".These need to be treated as single
T_LNUMBERtoken with a value of"0o777"to be processed correctly by phpcs