tests/Fixtures/Integration/misc/PHP8_0.test) ensuring all new syntaxes are passing complex ruleset like @Symfony or @PhpCsFixer:risky) (https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/5399)- GMP:
. gmp_random() has been removed. One of gmp_random_range() or
gmp_random_bits() should be used instead.
- OCI8:
. The OCI-Lob class is now called OCILob, and the OCI-Collection class is now
called OCICollection for name compliance enforced by PHP 8 arginfo
type annotation tooling.
. Several alias functions have been marked as deprecated.
- Reflection:
. The method signatures
ReflectionClass::newInstance($args)
ReflectionFunction::invoke($args)
ReflectionMethod::invoke($object, $args)
have been changed to:
ReflectionClass::newInstance(...$args)
ReflectionFunction::invoke(...$args)
ReflectionMethod::invoke($object, ...$args)
Code that must be compatible with both PHP 7 and PHP 8 can use the following
signatures to be compatible with both versions:
ReflectionClass::newInstance($arg = null, ...$args)
ReflectionFunction::invoke($arg = null, ...$args)
ReflectionMethod::invoke($object, $arg = null, ...$args)
Additional source: https://github.com/php/php-src/blob/php-8.0.0rc1/UPGRADING
composer.json of the project will be done after all current functionality has been made compatible (new feature support can wait)nightly as allowed to fail. When there is a dedicated Travis target for PHP8 we will add it to the stepsUnion Types rule should definitely support sorting to prevent !n possible orders. Probably based on phpdoc rules where there is alrady option for it.
Note that this issue is not about implementing new rules but making sure that existing rules do not break with new PHP 8.0 syntax changes. Nice suggestion though :+1:
More changes to the lexer: https://github.com/sebastianbergmann/php-token-stream/issues/95. (https://github.com/php/php-src/pull/5182)
@SpacePossum that RFC has been rejected. Voting closed yesterday, and they failed to get a 2/3 majority (only managed 58.9%).
@GrahamCampbell can you link the RFC? php/php-src#5182 appears to be accepted and merged (despite the closed PR status).
Would a dedicated Travis CI job for PHP 8.0 be a part of the definition of done for this issue? I know there is a nightly builds job, but that differs from pointing to a release of PHP 8.0 (even if it is beta).
Would a dedicated Travis CI job for PHP 8.0 be a part of the definition of done for this issue?
If Travis CI supports dedicated PHP 8.0 jobs, I would say yes.
https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/5114 gets us started with some stuff. If anyone could work out why that\s not working, that'd be a help.
PHP 8.0 Wiki Page and Timetable - GA Release 11/26/2020
PHP 8.0.0RC1 Upgrade Notes - information on new features and backwards-incompatible changes.
Implemented RFCs for 8.0 - a good place to learn of language changes that would most affect this project
I took some time to review all the core changes in the upgrade notes and their respective RFCs. I picked out the ones that had syntax changes, or I otherwise felt might break a rule.
I created a Google Sheet to track these potentially rule-breaking changes. Anyone can comment on this sheet. Please request edit permissions if desired:
removed link to avoid confusion
This is just a quick-and-dirty organization technique for myself that I thought would be useful; if there is a better place to organize this (like in this GitHub issue description?) let me know.
Edit: PHPCompatibility has a nice checklist of changes as well. I also like how they organized the tasks.
@hamdrew To be honest I prefer tracking PHP changes here, I updated the description. Hopefully I didn't forget anything important.
@julienfalque I agree! I removed the link to avoid confusion.
Last night I set up a PHP 8 docker environment to develop from. I share it here if anyone finds it useful: https://github.com/hamdrew/PHP-CS-Fixer-Docker
I didn't want to contribute a docker development environment directly to this project because that is a large discussion that doesn't need to happen right now.
I addressed the SplFixedArray issue first in #5167, since it was prohibiting a lot of tests from running.
@SpacePossum To what branch would you like php8-related PRs to be targeted? I chose master for now.
Thanks @hamdrew for the work in the PR!
Currently I'm working in PHP8 support as well in https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/5166 , for now I picked 2.15 to see what we can do for as many as branches we support.
@SpacePossum Cool, I'll target the same branch in my PRs to be consistent.
Would it be possible to bump this package from "php": "^5.6 || ^7.0", to "php": "^5.6 || ^7.0 || ^8.0", in order not to block other package. Atm php-webdriver/php-webdriver is blocked among others.
I understand that this issue tackle a larger overhaul, but would be great to get out of the blocking situation.
From the description:
Updating composer.json of the project will be done after all current functionality has been made compatible (new feature support can wait)
We are not going to break the code of our users, so "no" for now
@SpacePossum absolutely. I was not proposing to break anything.
Will it be possible to view a list of the current functionality that is not compatible with 8?
@viezel Please read the original post of this thread.
The best fix for your issue is to not depend directly on PHP CS Fixer at all, not even in require-dev. Install it separately instead, e.g.:
$ mkdir -p tools/php-cs-fixer
$ composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixer
Unless you develop some extension for it, PHP CS Fixer is not a dependency of your code but a tool.
There is also a nice vendor-bin plugin for composer which does this too.
See, for example: https://github.com/vlucas/phpdotenv.
For GitHub Actions, php-cs-fixer can be easily installed thanks to shivammathur/setup-php even on PHP 8
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ${{ matrix.php }}
tools: php-cs-fixer:2.16.7
folks, be aware that PHP CS Fixer does not let itself to be installed on PHP 8 not because we are willing to add some extra feature that will improve PHP 8 syntax, but because if you run PHP CS Fixer and feed it with code written in PHP 8, tool itself can crash, or worse - it will not crash and write back to your PHP file with invalid syntax, as PHP CS Fixer is not yet fully aware about syntax changes brought bu PHP 8
NB Executing php-cs-fixer on PHP 8.0 is not officially supported yet, so use with care!
@viezel Please read the original post of this thread.
The best fix for your issue is to not depend directly on PHP CS Fixer at all, not even in
require-dev. Install it separately instead, e.g.:$ mkdir -p tools/php-cs-fixer $ composer require --working-dir=tools/php-cs-fixer friendsofphp/php-cs-fixerUnless you develop some extension for it, PHP CS Fixer is not a dependency of your code but a tool.
I totally agree. But I do not control the https://github.com/php-webdriver/php-webdriver repo.
It's on a dev-dep, so doesn't block you installing it. It blocks them testing on PHP 8 however. They should remove it from their require-dev, as per the suggestions in the above comments here.
For GitHub Actions, php-cs-fixer can be easily installed thanks to shivammathur/setup-php even on PHP 8
@vincentchalamon This does not seem to be the case, at least not any more. I'm getting the following error when trying to include 8.0 in my build matrix, and pinning php-cs-fixer to 2.16.7 with the shivammathur/setup-php action:
PHP needs to be a minimum version of PHP 7.1.0 and maximum version of PHP 7.4.*.
@christeredvartsen If you want to disable that check you can use PHP_CS_FIXER_IGNORE_ENV=1 I don't know the consequences of this, so use with caution, but it will work with PHP 8 :smile:
@canvural Thanks, works in my case. Guess I'll keep an extra set of eyes on this build step until php-cs-fixer officially supports PHP 8.0. Thanks for the tip!
WDYT of an OptionalArgumentsFixer which would remove arguments whose value is their default鈥檚?
<?php chunk_split('This should be changed', 76);
would become
<?php chunk_split('This should be changed');
An additional boolean name_arguments option could determine whether
<?php chunk_split('This may be changed', 76, "\n");
would stay unchanged or become
<?php chunk_split('This may be changed', end: "\n");
due to changes in PHP parser and syntax, running PHP CS Fixer under PHP 8 can change meaning of your code (While tool itself will not crash, as code syntax is still valid after the change, yet it's meaning is different). Be warned when using PHP_CS_FIXER_IGNORE_ENV=1.
@MatTheCat for new feature requests, please raise dedicated issue or send a PR
Hi, is there a beta or development version/branch where I can install PHP CS Fixer with PHP 8?
This issue is 1 year old, and seems to be far from complete. Is there any ETA on availability of a release compatible with PHP 8?
PHP CS Fixer is currently preventing us from upgrading to PHP 8, and I'd hate to have to remove it :/
Welcome to open source @BenMorel, if you are that dependent on the project maybe consider supporting the developer financially, e.g. via GitHub sponsorship. It is also worth noting that PHP 8 has only been fully released a bit over a week ago, so maybe have some patience?
@BenMorel If I understood this thread correctly you can use PHP_CS_FIXER_IGNORE_ENV=1 to bypass the version constraint. Use at your own risk.
Sorry, I didn't mean to be rude, I also maintain a couple open source projects myself, and I do understand that it's a lot of time investment. Let me simply rephrase my question as:
When can we expect a PHP 8 -compatible release?
The effort needed to have basic support of new syntax (so to only understand it and don't break the code, not talking about effort to write new rules to adjust new syntax) is insane, for that, there is now ETA for PHP 8 support release.
I understand that this is not best situation, but amount of folks investing their private, free time is very limited.
If you want to speed up PHP 8 support, please take a look at TODO in opening message and help with one of it.
composer install on PHP8 is now possible with the release of 2.17:
https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/5326
For people complaining that PHP 8 doesn't work, remember this is an OSS project. It is much your job to make it work as it is anyone elses'. If you need a feature, consider implementing it yourself or asking for a quote for someone else to do it for you.
Based on the reasoning to not allow usage of the tool in #5341
The result running PHP CS Fixer on code with it is not known, currently.
We already had a case when PHP 8 code was parsed, changed by fixer and produced valid PHP syntax, but with different meaning. We don't want to offer that to users of the tool. In our opinion it's better to not offer the tool than offer the tool and break the code logic.
Would it be an idea to give the user a warning when someone uses ./vendor/bin/php-cs-fixer with PHP 8.0 instead of terminating execution?
or at least the info how to use PHP_IGNORE_ENV.
would you mind to add that note, @SanderSander ?
@keradus Ah sorry guess I'm getting tired that would be way better 馃槄 I will add some documentation about PHP_CS_FIXER_IGNORE_ENV
Most helpful comment
For people complaining that PHP 8 doesn't work, remember this is an OSS project. It is much your job to make it work as it is anyone elses'. If you need a feature, consider implementing it yourself or asking for a quote for someone else to do it for you.