When we need to evaluate constant ASTs, we always have to do that in
the scope where the constant has been defined, which may be a parent
of the `ReflectionClass`'s scope.
Closes GH-8106.
By switching attribute constructor stackframe to be called via
trampoline the stack allocation is not causing dangling pointers
in the zend_observer API anymore.
Co-Authored-By: Florian Sowade <f.sowade@suora.com>
Co-Authored-By: Christopher Becker <cmbecker69@gmx.de>
Co-Authored-By: Dmitry Stogov <dmitry@zend.com>
Closes GH-7885.
Requiring all internal classes (including those from 3rd-party
extensions) to implement Stringable if they provide __toString()
is too error prone. Case in point, our _ZendTestClass test class
was not doing so, resulting in preloading test failures after
recent changes.
Instead we automatically implement Stringable, the same as we do
for userland classes. We still allow explicit implementations,
but ignore them (normally they would result in an error due to
duplicate interface implementation). Finally, we need to be
careful about not trying to implement Stringable on Stringable
itself.
In some cases this changes the interface order, in particular the
automatic Stringable implementation will now come first.
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.
