Add more accurate types to stubs again #6068
Conversation
| @@ -1221,8 +1221,8 @@ static zend_always_inline zval *zend_try_array_init(zval *zv) | |||
| _(Z_EXPECTED_DOUBLE_OR_NULL, "of type ?float") \ | |||
| _(Z_EXPECTED_NUMBER, "of type int|float") \ | |||
| _(Z_EXPECTED_NUMBER_OR_NULL, "of type int|float|null") \ | |||
| _(Z_EXPECTED_STRING_OR_ARRAY, "of type string|array") \ | |||
| _(Z_EXPECTED_STRING_OR_ARRAY_OR_NULL, "of type string|array|null") \ | |||
| _(Z_EXPECTED_STRING_OR_ARRAY, "of type array|string") \ | |||
There was a problem hiding this comment.
So that we use the canonical form. I'll carve out these changes to a separate commit.
kocsismate
force-pushed
the
more-accurate-types3
branch
2 times, most recently
from
66dc599 to
c4dce3b
Compare
kocsismate
force-pushed
the
more-accurate-types3
branch
from
c4dce3b to
307b242
Compare
Oh gosh, I didn't know it :/ But! I could compile snmp (actually, there was a warning about an unused variable). Unfortunately, I could only run a function reflection test, which was failing - but instead of fixing it, I rather removed it. |
kocsismate
force-pushed
the
more-accurate-types3
branch
2 times, most recently
from
9540d95 to
c6a712d
Compare
kocsismate
force-pushed
the
more-accurate-types3
branch
from
c6a712d to
f967898
Compare
| @@ -1577,6 +1580,23 @@ ZEND_API ZEND_COLD void zend_argument_value_error(uint32_t arg_num, const char * | |||
| #define Z_PARAM_OBJECT_OR_NULL(dest) \ | |||
| Z_PARAM_OBJECT_EX(dest, 1, 0) | |||
|
|
|||
| #define Z_PARAM_OBJ_EX2(dest, check_null, deref, separate) \ | |||
There was a problem hiding this comment.
I added a Z_PARAM_OBJ which uses the zend_object type, rather than zval. If it was a bad idea, I can revert it, but I felt that it would help the previous efforts to migrate our APIs from zvals to zend_object.
There was a problem hiding this comment.
Maybe add a comment above it, so it's obvious what the difference is?
|
Now, there is only a handful of functions remaining which have a parameter for which a native type could/might be worth to add with a relatively small effort:
Is it really worth to add a ZPP macro for them? If so, I'll create a one last PR for migrating custom type checks to ZPP. |
It's built on AppVeyor at least, if I'm not mistaken. I worked a bit on the test suite months ago (Debian), but it is still partially broken, because it depends on certain data files in certain locations. Would be really good to have some maintainer for ext/snmp. |
| @@ -1577,6 +1580,23 @@ ZEND_API ZEND_COLD void zend_argument_value_error(uint32_t arg_num, const char * | |||
| #define Z_PARAM_OBJECT_OR_NULL(dest) \ | |||
| Z_PARAM_OBJECT_EX(dest, 1, 0) | |||
|
|
|||
| #define Z_PARAM_OBJ_EX2(dest, check_null, deref, separate) \ | |||
There was a problem hiding this comment.
Maybe add a comment above it, so it's obvious what the difference is?
| static const php_password_algo* php_password_algo_find_zval(zval *arg) { | ||
| return php_password_algo_find_zval_ex(arg, php_password_algo_default()); | ||
| static const php_password_algo* php_password_algo_find_zval(zend_string *arg_str, zend_long arg_long, zend_bool arg_is_null) { | ||
| return php_password_algo_find_zval_ex(arg_str, arg_long, arg_is_null, php_password_algo_default()); |
There was a problem hiding this comment.
php_password_algo_find_zval_ex is used only here, I'd inline it.
No description provided.