Implement "Deprecate functions with overloaded signatures" RFC for PHP 8.3#11703
Implement "Deprecate functions with overloaded signatures" RFC for PHP 8.3#11703kocsismate merged 13 commits intophp:masterfrom
Conversation
|
I did not review this yet, but the PR is missing checks for exceptions promoted by error handlers after |
Girgias
left a comment
There was a problem hiding this comment.
I made a first pass with some comments, I skipped FFI and Date, but the other ones mostly seem to make sense.
ext/dba/dba.c
Outdated
| zend_error(E_DEPRECATED, "Calling dba_fetch() with $dba at the 3rd parameter is deprecated", | ||
| ZSTR_VAL(fbc->common.function_name)); |
There was a problem hiding this comment.
Ah yes, there used to be a %s instead of dba_fetch(), and I forgot to remove the parameter.
3ebc7ea to
ad1e175
Compare
|
I squashed the fixups because there were too many of them. Sorry for that! |
ad1e175 to
37ff351
Compare
Girgias
left a comment
There was a problem hiding this comment.
I am fine with already merging the DBA, Intl, Reflection, Phar, PGSQL, and stream PRs.
FFI and get_class() has legit CI failures.
|
Actually the intl and postgress also have CI failures on Windows. |
Thanks for the reminder, I've just tried to fixed them. Turned out that I had a bug in the pgsql code... I'll also try to fix the FFI memleaks tomorrow. Unfortunately, I cannot reproduce them locally, but at least I have a suspecicion where the issue lies. |
|
I can reproduce the FFI failures with ASAN, and the memory leak is a pre-existing issue, which I assume is related to something not being cleaned-up on failure when the FFI object is being destroyed. To not have this be blocking, either XFAIL this or revert the 3 tests to use the static method and emit the deprecation notice. @dstogov (or @bwoebi) I'm imagining the issues is related to the FFI destructors not properly cleaning up after themselves if not called statically. The fix should also be backported to supported versions. |
039945f to
b85db30
Compare
Relevant test PR: #11720 |
iluuu1994
left a comment
There was a problem hiding this comment.
To clarify: It is common for PHP code to register error handlers that promote errors to exceptions. In these cases, the called functions shouldn't actually take effect, i.e. execute, so we need to abort accordingly with `if (UNEXPECTED(EG(exception)) { possibly_cleanup(); RETURN_THROWS(); }
Zend/zend_vm_def.h
Outdated
| if (UNEXPECTED(EG(exception))) { | ||
| HANDLE_EXCEPTION(); | ||
| } else { | ||
| ZEND_VM_NEXT_OPCODE(); |
There was a problem hiding this comment.
Nit: No need to move this line.
ext/ldap/ldap.c
Outdated
| char *wallet = NULL, *walletpasswd = NULL; | ||
| size_t walletlen = 0, walletpasswdlen = 0; | ||
| zend_long authmode = GSLC_SSL_NO_AUTH; | ||
| int ssl = 0; |
…lendar::createFromDateTime()
…eld_is_null() nullable
a88a1ea to
08f8651
Compare
| @@ -205,6 +205,8 @@ class ReflectionMethod extends ReflectionFunctionAbstract | |||
|
|
|||
| public function __construct(object|string $objectOrMethod, ?string $method = null) {} | |||
There was a problem hiding this comment.
According to RFC the last argument should be required
There was a problem hiding this comment.
Is there follow-up for that? or passing one argument will remain til 8.4 as freeze in action?
https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures#reflectionmethodconstruct
There was a problem hiding this comment.
The RFC lists the last parameter as required only in one of the signatures, but since there is another one with 1 parameter, the stub - which unified the two signatures - displays the 2nd parameter as optional.
Is there follow-up for that?
What kind of follow-up do you mean? According to the RFC, the signatures and the behavior of ReflectionMethod::__construct() won't change until 9.0, except for the signature with 1 parameter will be deprecated in PHP 8.4. In 9.0, the constructor will only accept 2 arguments.
There was a problem hiding this comment.
Thank you! misread
deprecate the second constructor signature in PHP 8.4
|
Hello, this introduced: But no alternative is given, and documentation still promote this way to set static properties: So what to do in this particular case, and more generally, how do you expect developers to find out the fixes when hitting those kind of deprecations? [EDIT] Found |
|
Hi @kylekatarnls , Thanks for the investigation! The RFC suggests another alternative: the the relevant section in https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures |
Migrations strategies will be written as part of the migration docs which are yet to be written. |
Implementation for https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signatures. Each subvote has a separate commit.