We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
Make ReflectionAttribute::newInstance() respect the strict_types=1
declaration at the attribute use-site. More generally, pretend that
we are calling the attribute constructor from the place where the
attribute is used, which also means that the attribute location will
show up properly in backtraces and inside "called in" error information.
This requires us to store the attributes strict_types scope (as flags),
as well as the attribute line number. The attribute filename can be
recovered from the symbol it is used on. We might want to expose the
attribute line number via reflection as well.
See also https://externals.io/message/111915.
Closes GH-6201.
ReflectionReference::fromArrayElement(array $array, int|string $key): ?ReflectionReference
is going to be its official signature for PHP 8.0.
Closes GH-5651
* The array "subject" of a function gets called $array.
* Further parameters should be self-descriptive if used
as a named parameter, and a full word, not an abbreviation.
* If there is a "bunch more arrays" variadic, it gets
called $arrays (because that's what was already there).
* A few functions have a variadic "a bunch more arrays,
and then a callable", and were already called $rest.
I left those as is and died a little inside.
* Any callable provided to an array function that acts
on the array is called $callback. (Nearly all were already,
I just fixed the one or two outliers.)
* array_multisort() is beyond help so I ran screaming.
The second and third arguments are not always the sort_order and
sort_flags -- they can also be in reverse order, or be arrays
altogether. Move them into the variadic parameter to avoid awkward
error messages.
"Fix" in the sense of "not crash". We aren't able to actually
display the default value for this case, as there's no way to
fetch the relevant information right now.
This is targeting 8.0.
`$arg` seems like a poor choice of a name,
especially if the function were to have arguments added.
In many cases, the php.net documentation already has $array for these functions.
E.g. https://www.php.net/manual/en/function.array-intersect.php
I'd assume that since named arguments was added to 8.0 near the feature freeze,
PHP's maintainers had planned to make the names consistent
and gradually use the same name for docs and implementation.
From an engine perspective, named parameters mainly add three
concepts:
* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.
RFC: https://wiki.php.net/rfc/named_params
Closes GH-5357.
RFC: https://wiki.php.net/rfc/saner-numeric-strings
This removes the -1 allow_error mode from is_numeric_string functions and replaces it by
a trailing boolean out argument to preserve BC in a couple of places.
Most of the changes can be resumed to "numeric" strings which emitted a E_NOTICE now emit
a E_WARNING and "numeric" strings which emitted a E_WARNING now throw a TypeError.
This mostly affects:
- String offsets
- Arithmetic operations
- Bitwise operations
Closes GH-5762
Bug that regularly sneaks in: ZEND_ACC_FINAL is set before calling
zend_register_internal_class() and promptly gets ignored. Remove
this footgun by preserving flags from the original CE.
