Skip to content
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

Account for changes introduced in PHP 8.0 #809

Open
24 of 40 tasks
jrfnl opened this issue Jun 1, 2019 · 0 comments
Open
24 of 40 tasks

Account for changes introduced in PHP 8.0 #809

jrfnl opened this issue Jun 1, 2019 · 0 comments

Comments

@jrfnl
Copy link
Member

jrfnl commented Jun 1, 2019

This is just an issue to keep track of which of the implemented RFCs for PHP 8.0 have been addressed.

This list should be updated when additional RFCs are accepted/implemented.

To Do

  • Reclassifying engine warnings
    Reevaluate the current level of various engine notices/warnings
    Notes:
    • For the new "argument # must be passed by reference" warning: while we may not be able to detect this for userland functions, we should be able to use the list of PHP native functions combined with reflection to check if any arguments is expected to be passed by reference and trigger a warning if a non-variable is passed in that position.
      Beware of changes in the PHP native function method signature across versions though! Reflection will only know the signature as per the PHP version the sniff is run on.
  • Saner string to number comparison
    Proposes to change non-strict comparisons between strings and numbers to behave more reasonably.
  • Saner numeric strings
  • Make sorting stable
    Make all sorts in PHP stable by default
    Notes after initial RFC review (by @jrfnl):
    • There isn't really anything sniffable for the actual sorting change, as to determine whether this would be problematic depends on how and where the output of the sort is used, which is beyond basic static analysis.
    • However... custom sorting functions returning a boolean value instead of an integer value are now deprecated and, up to a point, detecting those kind of custom sorting functions would be sniffable.
      Notes for implementation:
      • Check the callback parameter of those sorting functions which take a callback.
      • If the callback is a native PHP function, use reflection to get the return type.
      • If the callback is a closure or arrow function (short closure), try to determine the type of the return value by looking for a return type in the closure signature and if not found, looking at all return statements within the closure.
      • If the callback is a method in an anonymous class passed as the callback, find the method within the anonymous class (if available and not inherited from a parent class) and try to determine the type of the return value, potentially using the method docblock (if available) as a fallback if the type cannot be determined from a return type declaration or the return statement(s).
      • If the callback is a method and the method is from the current class, find the method declaration and try to determine the return type.
      • If the callback is a method and the sorting call is outside class or in another class, see if that class happens to be declared in the current file, find the method declaration and try to determine the return type.
      • If the callback is a global or namespaced function, see if the declaration can be found in the current file and try to determine the return type.
        This case will have the least chance of successfully determining the type.
      • If the return type could be determined and is boolean, throw a deprecation warning.
  • Locale-independent float to string cast
  • Change default PDO error mode
  • Stricter type checks for arithmetic/bitwise operators
  • Always generate fatal error for incompatible method signatures
    Resolve inconsistent handling of abstract and non-abstract methods during inheritance.
  • Always generate fatal error for incompatible method signatures
    Resolve inconsistent handling of abstract and non-abstract methods during inheritance.
    Notes after initial RFC review (by @jrfnl):
    • For classes implementing PHP native interfaces, a registry with the method signatures could be created and the signature of methods implementing the interface could be checked against the registry.
    • IIRC PHP doesn't natively have any traits, but it would need to be checked if there are any abstract classes which need to be handled too.
    • Having said that, this would still not be straight forward as the types in the signature declaration would need to be checked with LSP in mind, which comes with its own set of problems if the type is an OO type (we don't know the inheritance chain). That's of course, aside from the "simple" LSP issues which would need to be dealt with, like int being contravariant with float and array being co-variant with ?array or array|false.
    • For userland interfaces/traits/parent classes, the only case in which this could reliably be checked, is when the interface/trait and the class implementing the interface/using the trait would be declared in the same file, however, as it is uncommon to have multiple OO structures defined in the same file, as the fast majority of PHP projects adhere to PSR-4, this would be an edge case. Also see Signature of abstract methods defined in traits is checked against the implementing class method in php 8+ #1712
    • All in all, it's probably not worth the time investment needed to write this sniff for the very, very few cases which could be detected.
  • Consistent type errors for internal functions
    Consistently throw TypeError for parameter parsing failures of internal functions.
    Notes:
    • For this, we'd need to build up a list of the functions and their parameters for which this change has been implemented and check the type of the parameter passed if hard-coded, ignore when variable, constant or output of function call. Can't use Reflection here as a lot of these were changed in PHP 8 and earlier PHP versions will not give the right information.
      Mind: there are a lot of PRs in php-src to go through to find all the changes.

Aside from the RFCs, there are also the changes which were made outside of the RFC process and are listed in:

Claimed

Has PR

Reviewed and concluded non-sniffable

  • Don't automatically unserialize Phar metadata outside getMetadata()
    Review: Unless and until PHPCompatibility would start examining method calls with object variable resolution, there is nothing in this RFC (or the related PR/commit) which is sniffable.
  • Always available JSON extension
    Review: The only thing which would be sniffable would be to detect calls to extension_loaded('json') and the likes. Those calls are no longer necessary, but as those will continue to work without notices, this is not a PHPCompatibility issue.

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.0 comes out, individual issues should be opened for the changes which remain at that point in time.

@jrfnl jrfnl pinned this issue Jul 4, 2019
sebastianstein added a commit to in2code-de/in2studyfinder that referenced this issue Oct 28, 2022
Note:

php-compatibility does currently not find all violations.
For further information see: PHPCompatibility/PHPCompatibility#809
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant