Currently, trait methods are aliased will continue to use the
original function name. In a few places in the codebase, we will
try to look up the actual method name instead. However, this does
not work if an aliased method is used indirectly
(https://bugs.php.net/bug.php?id=69180).
I think it would be better to instead actually change the method
name to the alias. This is in principle easy: We have to allow
function_name to be changed even if op array is otherwise shared
(similar to static_variables). This means we need to addref/release
the function_name separately, but I don't think there is a
performance concern here (especially as everything is usually
interned).
There is a bit of complication in opcache, where we need to make
sure that the function name is released the correct number of times
(interning may overwrite the name in the original op_array, but we
need to release it as many times as the op_array is shared).
Fixes bug #69180.
Fixes bug #74939.
Closes GH-5226.
Make ReflectionClassConstant->class the declaring class, not the
class on which the constant was fetched. This matches the behavior
for properties and methods.
RFC: https://wiki.php.net/rfc/static_return_type
The "static" type is represented as MAY_BE_STATIC, rather than
a class type like "self" and "parent", as it has special
resolution semantics, and cannot be cached in the runtime cache.
Closes GH-5062.
Make sure we still perform a zpp check for the static case, and
also always enforce that the parameter is ?object. Otherwise we
violate the specified signature.
Instead of having a completely independent encoding for type list
entries. This is going to use more memory, but I'm not particularly
concerned about that, as type unions that contain multiple classes
should be uncommon. On the other hand, this allows us to treat
top-level types and types inside lists mostly the same.
A new ZEND_TYPE_FOREACH macros allows to transparently treat list
and non-list types the same way. I'm not using it everywhere it could be
used for now, just the places that seemed most obvious.
Of course, this will make any future type system changes much simpler,
as it will not be necessary to duplicate all logic two times.
According to RFC: https://wiki.php.net/rfc/union_types_v2
The type representation now makes use of both the pointer payload
and the type mask at the same time. Additionall, zend_type_list is
introduced as a new kind of pointer payload, which is used to store
multiple class types. Each of the class types is a tagged pointer,
which may be either a class name or class entry. The latter is only
used for typed properties, while arguments/returns will instead use
cache slots. A type list can contain a mix of both names and CEs at
the same time, as not all classes may be resolvable.
One thing this is missing is support for union types in arginfo
and stubs, which I want to handle separately.
I've also dropped the special object code from the JIT implementation
for now -- I plan to add this back in a different form at a later time.
For now I did not want to include non-trivial JIT changes together
with large functional changes.
Another possible piece of follow-up work is to implement "iterable"
as an internal alias for "array|Traversable". I believe this will
eliminate quite a few special-cases that had to be implemented.
Closes GH-4838.
We now store the pointer payload and the type mask separately. This
is in preparation for union types, where we will be using both at
the same time.
To avoid increasing the size of arginfo structures, the
pass_by_reference and is_variadic fields are now stored as part of
the type_mask (8-bit are reserved for custom use).
Different types of pointer payloads are distinguished based on bits
in the type_mask.
Public/protected properties defined in parent classes will be
inherited in the child -- there is no need to explicitly try to
walk up the chain and look them up.
Instead of constructing a dummy property_info for dynamic properties,
leave the field as NULL and handle this as appropriate.
This was originally part of an alternative fix for bug #78774, but
I think doing it this way is generally preferrable independently
of that.
The string held by the zend_type may be released if the property
type gets resolved to a CE. I initially wanted to fix this by
storing a zend_type* instead (so the property type resolution
propagates to the ReflectionType), but decided against this in
light of upcoming union types support, where we also need to
represent parts of the union, and will not have a single zend_type*
we can reference.
Since `zend_parse_parameters()` throws now, there is no reason to
explicitly call `zend_parse_parameters_throw()` anymore, and since both
have actually the same implementation, we redefine the latter as macro.
Add deprecated _ZendTestClass::__toString() method to preserve
an existing test.
ReflectionType::__toString() will now return a complete
representation of the type, as it should have originally. Users
that relied on nullability being absent should have been pushed
to ReflectionNamedType::getName() by the deprecation of
ReflectionType::__toString() in PHP 7.1 / PHP 7.4.
* pack() only requires one argument
* stream_context_set_option() only requires two arguments
* ReflectionMethod::getClosure() accepts no args for static methods
* DOMDocument::createProcessingInstruction() only requires one arg
* DOMImplementation::createDocument() only requires two arguments
* DOMDocument::importNode() only requires one arg
* mysql_get_client_version() doesn't accept any args,
despite what the docs say...
`get_closure` handlers are called to check whether an object is
callable, and to actually get the closure, respectively. The behavior
of the handler might differ for these two cases, particularly the
handler may throw in the latter case, but should not in the former.
Therefore we add a `check_only` parameter, to be able to distinguish
the desired purpose.
Use value 0 instead. To compensate we check in ReflectionParameter
allowsNull() whether the type is set at all: If it isn't, it always
allows null.
This removes a discrepancy between internal&userland functions:
For userland functions allowsNull() on untyped parameters returned
true, but for internal functions it returned false.
