vsprintf(): Argument #2 ($values) must be of type array, string given
afilina opened this issue · comments
Bug Description
Fresh installation crashes with a fatal error during scan.
Given the following reproduction Scenario
./vendor/bin/phpcs -p ./project --standard=PHPCompatibility --runtime-set testVersion 8.3With a file containing this statement:
<?php
iconv_set_encoding('internal_encoding', $encoding);I'd expect the following behaviour
Compatibility report.
Instead this happened
At 85% of scanning the repo:
PHP Fatal error: Uncaught TypeError: vsprintf(): Argument #2 ($values) must be of type array, string given in /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/File.php:1085
Stack trace:
#0 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/File.php(1085): vsprintf()
#1 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/File.php(735): PHP_CodeSniffer\Files\File->addMessage()
#2 /home/afilina/www/phpcompat/vendor/phpcompatibility/php-compatibility/PHPCompatibility/Sniffs/ParameterValues/RemovedIconvEncodingSniff.php(79): PHP_CodeSniffer\Files\File->addWarning()
#3 /home/afilina/www/phpcompat/vendor/phpcompatibility/php-compatibility/PHPCompatibility/AbstractFunctionCallParameterSniff.php(138): PHPCompatibility\Sniffs\ParameterValues\RemovedIconvEncodingSniff->processParameters()
#4 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/File.php(519): PHPCompatibility\AbstractFunctionCallParameterSniff->process()
#5 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/LocalFile.php(92): PHP_CodeSniffer\Files\File->process()
#6 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Runner.php(647): PHP_CodeSniffer\Files\LocalFile->process()
#7 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Runner.php(453): PHP_CodeSniffer\Runner->processFile()
#8 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Runner.php(119): PHP_CodeSniffer\Runner->run()
#9 /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/bin/phpcs(14): PHP_CodeSniffer\Runner->runPHPCS()
#10 /home/afilina/www/phpcompat/vendor/bin/phpcs(119): include('...')
#11 {main}
thrown in /home/afilina/www/phpcompat/vendor/squizlabs/php_codesniffer/src/Files/File.php on line 1085
Environment
| Environment | Answer |
|---|---|
| PHP version | 8.2.3 |
| PHP_CodeSniffer version | 3.9.1 |
| PHPCSUtils version | (not in lock file) |
| PHPCompatibility version | 9.3.5 |
| Install type | composer-project-method-1 |
Tested Against develop branch?
- I have verified the issue still exists in the
developbranch of PHPCompatibility.
This was fixed in #1212, which will be included in PHPCompatibility 10.0.0. If you want to use PHPCompatibility on PHP 8.0 or higher, use the develop branch. 9.3.5 was released before 8.0 was out. (and yes, I know, we really should get 10.0.0 release ready, but there are only so many hours in a day...)
Can't find a better place for this discussion, so I'll try here.
Since 10.0 is such a big undertaking, does it make sense to continue with 9.x fixes in a separate branch so that we could have PHP 8 compatible releases until then? I'll try to contribute to it. Some of these PRs are really pretty easy, even if there are several years of them.
@afilina I feel your pain, but no, that is not on the table (and has been discussed multiple times before, see #1468, #1284, #1651).
Tagging a 9.x version now would give people the impression that that version is ready to deal with current PHP syntaxes and that is just not the case and never will be.
With everything that's on my plate, I'm absolutely not prepared to add the mental overhead of maintaining two branches, let alone the workload of backporting things from 10.0/develop.
So, sorry, but if you want the latest and greatest of PHPCompatibility and want to run on PHP 8.0+, use the develop branch, otherwise, run on PHP <= 7.4 and feel free to use 9.3.5.
Understandable. Thanks and take care!