This is just an issue to keep track of which of the implemented RFCs for PHP 8.4 have been addressed.
This list should be updated when additional RFCs are accepted/implemented.
To Do
Aside from the RFCs, there are also the changes which were made outside of the RFC process and are listed in:
Claimed
Additionally, an initial scan of UPGRADING file for additional list-based updates to be made is ongoing and owned by @jrfnl.
Has PR
Reviewed and concluded non-sniffable
- Change how JIT is disabled by default
Review notes: This is a change to the default value of ini configuration settings. Previously the opcache.jit_buffer_size (INI_SYSTEM) ini would need to be set to a non-0 value to enable JIT. Now the opcache.jit (INI_ALL but only when not set to disable) ini will need to be changed from disable to any of the other valid values.
As these ini configuration changes cannot be made at run-time, but must be made in a php.ini file, there is nothing to sniff for.
- A new JIT implementation based on IR Framework
Review notes: doesn't appear to have any sniffable implications.
- Increasing the default BCrypt cost
Review notes: this has no impact on userland code, other than in performance. As the cost is included in the hash, the password hashes are cross-version compatible anyhow.
Note that password_hash() returns the algorithm, cost and salt as part of the returned hash.
Therefore, all information that's needed to verify the hash is included in it.
This allows the verify function to verify the hash without needing separate storage for the salt or algorithm information.
Source: https://www.php.net/manual/en/function.password-verify.php
Delayed to later PHP version
- (in part) Dedicated StreamBucket class
👉 Note: the RFC includes a proposal to deprecate the $datalen property in the return value in favour of the (new) $dataLength property.
This proposal, however, is slated for the next PHP version (8.5 or 9.0), not for PHP 8.4.
- Deprecations for PHP 8.4
Sublist:
Status yet to be determined
These are RFCs which have either not yet been implemented or are still in voting at this time.
Once their final status for PHP 8.4 is determined, they will either be moved to the "To Do" list or removed from this ticket.
Accepted, not yet (fully) implemented
Feature freeze is in effect. Anything which didn't make it in yet, is delayed to a future PHP version.
In voting
All votes have been closed
Process
If anyone starts work on updating PHPCompatibility to handle any of these issues, please either update the above list (if you can) or leave a comment below, so one of the maintainers can update the list.
Once PHP 8.4 comes out, individual issues should be opened for the changes which remain at that point in time.
Guidelines
- When in doubt how to address something and/or if your approach is the right one: ask.
This also means that it is perfectly acceptable to open an dedicated issue to discuss a particular change in more detail.
- PRs which address RFCs should only contain the changes for one RFC per PR. One RFC may warrant multiple PRs depending on the nature of the changes.
Exception: when a RFC builds onto a previous RFC, combining the necessary changes into one PR addressing the cumulative changes to PHP is fine.
- PRs not directly related to RFCs may address multiple changes in one go as long as the changes are logically closely related (like adding a range of new constants to be detected).
- Please include relevant change justification and links in each commit message.
Typically this means that a commit message should include:
- Text snippet from the PHP
UPGRADING guide/changelog/migration guide or the RFC to back up the change being made.
- A link to the RFC (if applicable).
- A link to the exact
UPGRADING guide/changelog/migration guide section which documents the change in PHP Core.
- A link to the PR to PHP Core which proposed the change (if applicable).
- A link to the commit which added the change to PHP Core.
- Changes which were proposed/accepted for PHP, but have not been merged into PHP Core yet, should not be detected by PHPCompatibility (yet).
The commit to PHP Core should always come first, PHPCompatibility follows.
This is just an issue to keep track of which of the implemented RFCs for PHP 8.4 have been addressed.
This list should be updated when additional RFCs are accepted/implemented.
To Do
Review note: at this moment probably not sniffable as this only adds class constants and methods on (pre-)existing classes.
Note: these may not all be fully implemented yet! PRs to detect the deprecation will only be accepted after the deprecation has been merged into PHP Core.
Sublist:
Aside from the RFCs, there are also the changes which were made outside of the RFC process and are listed in:
Claimed
Status: will need to wait until it becomes clear how this will be supported in PHPCS itself and PHPCSUtils.
Owner: @jrfnl
Status: will need to wait until it becomes clear how this will be supported in PHPCS itself and PHPCSUtils.
Owner: @jrfnl
Sub-tasks:
#[\Deprecated]AttributeThis RFC proposes an attribute to mark declarations as deprecated
Status: TODO / needs a good think, see Further improve attribute detection/flagging #1935
Owner: @jrfnl
Status: WIP
Owner: @jrfnl
Additionally, an initial scan of UPGRADING file for additional list-based updates to be made is ongoing and owned by @jrfnl.
Has PR
BcMath\Number(RFC) #1765Note: the change in GMP cast behaviour is deemed unsniffable as it would require variable tracing.
BcMath\Number(RFC) #1765Sub-tasks:
PHPCompatibility.Interfaces.NewPropertiesInInterfacessniff (RFC) #1814finalproperties - PR PHP 8.4 | ✨ NewPHPCompatibility.Classes.NewFinalPropertiessniff (RFC) #1815abstractproperties - PR PHP 8.4 | ✨ NewPHPCompatibility.Classes.NewAbstractPropertiessniff #1901new MyClass()->method()without parentheses - PR PHP 8.4 | ✨ NewPHPCompatibility.Syntax.NewClassMemberAccessWithoutParenthesessniff [RFC] #1903PHPCompatibility.FunctionDeclarations.RemovedImplicitlyNullableParamsniff (RFC) #1694 + PHP 8.4 | FunctionDeclarations/RemovedOptionalBeforeRequiredParam: flag implicitly nullable parameters #1699http_(get|clear)_last_response_headers()function - PR PHP 8.4 | NewFunctions: detect use of new http_*_last_response_header() functions (RFC) #1756👉 Note: the RFC includes a proposal to deprecate the
$datalenproperty in the return value in favour of the (new)$dataLengthproperty.This proposal, however, is slated for the next PHP version (8.5 or 9.0), not for PHP 8.4.
Note: no sniff will be created to check
**andpow()operations for0with a negative power as it is deemed unlikely that any such calculations with both numbers hard-coded will ever be found and PHPCS is not suitable for variable value tracing throughout a codebase.PHPCompatibility.ParameterValues.RemovedProprietaryCSVEscapingsniff #1787Reviewed and concluded non-sniffable
Review notes: This is a change to the default value of ini configuration settings. Previously the
opcache.jit_buffer_size(INI_SYSTEM) ini would need to be set to a non-0 value to enable JIT. Now theopcache.jit(INI_ALLbut only when not set todisable) ini will need to be changed fromdisableto any of the other valid values.As these ini configuration changes cannot be made at run-time, but must be made in a
php.inifile, there is nothing to sniff for.Review notes: doesn't appear to have any sniffable implications.
Review notes: this has no impact on userland code, other than in performance. As the cost is included in the hash, the password hashes are cross-version compatible anyhow.
Delayed to later PHP version
👉 Note: the RFC includes a proposal to deprecate the
$datalenproperty in the return value in favour of the (new)$dataLengthproperty.This proposal, however, is slated for the next PHP version (8.5 or 9.0), not for PHP 8.4.
Sublist:
Status yet to be determined
These are RFCs which have either not yet been implemented or are still in voting at this time.
Once their final status for PHP 8.4 is determined, they will either be moved to the "To Do" list or removed from this ticket.
Accepted, not yet (fully) implemented
Feature freeze is in effect. Anything which didn't make it in yet, is delayed to a future PHP version.
In voting
All votes have been closed
Process
If anyone starts work on updating PHPCompatibility to handle any of these issues, please either update the above list (if you can) or leave a comment below, so one of the maintainers can update the list.
Once PHP 8.4 comes out, individual issues should be opened for the changes which remain at that point in time.
Guidelines
This also means that it is perfectly acceptable to open an dedicated issue to discuss a particular change in more detail.
Exception: when a RFC builds onto a previous RFC, combining the necessary changes into one PR addressing the cumulative changes to PHP is fine.
Typically this means that a commit message should include:
UPGRADINGguide/changelog/migration guide or the RFC to back up the change being made.UPGRADINGguide/changelog/migration guide section which documents the change in PHP Core.The commit to PHP Core should always come first, PHPCompatibility follows.