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.
This is a bit annoying: When preloading is used, types might be
resolved during inheritance checks, so we need to deal with CE
types rather than just NAME types everywhere.
We need to perform trait scope fixup for both methods involved
in the inheritance check. For that purpose we already need to
thread through a separate fn scope through the entire inheritance
checking machinery.
Voidification of Zend API which always succeeded
Use bool argument types instead of int for boolean arguments
Use bool return type for functions which return true/false (1/0)
Use zend_result return type for functions which return SUCCESS/FAILURE as they don't follow normal boolean semantics
Closes GH-6002
If we're validating a class method against a trait method, we need
to treat "self" in the trait method as the class where the method
is used. To achieve this, we need to thread the proto scope through
all methods, so it can be provided separately from proto.common->scope.
Closes GH-5353. From now on, PHP will have reflection information
about default values of parameters of internal functions.
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
Currently, when writing something like
class X {
use T1, T2 {
func as otherFunc;
}
function func() {}
}
where both T1::func() and T2::func() exist, we will simply assume
that func refers to T1::func(). This is surprising, and it doesn't
really make sense that this particular method gets picked.
This commit validates that non-absolute method references are
unambiguous, i.e. refer to exactly one method. If there is
ambiguity, it is required to write T1::func as otherFunc or
similar.
Closes GH-5232.
The place where interface implementation handlers is called is
currently ill-defined: If the class implements interfaces itself,
the handlers for both the parent interfaces and the new interfaces
will be called after all methods are registered (post trait use).
If the class does not implement interfaces, then the parent
interface handlers are called early during inheritance (before
methods are inherited).
This commit moves the calls to always occur after all methods are
available. For userland classes this will be post trait import,
at the time where interfaces get implemented (whether the class
itself defines additional interfaces or not). For internal classes
it will be at the end of inheritance, as internal class declarations
do not have proper finalization.
This allows us to simplify the logic for implementing the magic
Iterator / IteratorAggregate interfaces. In particularly we can
now also automatically detect whether an extension of
IteratorAggregate can safely reuse a custom get_iterator handler,
or whether it needs to switch to the userland mechanism. The
Iterator case continues to rely on ZEND_ACC_REUSE_GET_ITERATOR
for this purpose, as a wholesale replacement is not possible there.
I found what the modifier code does with XOR pretty confusing.
It's just removing the PPP bits...
Also remove an outdated reference to OVERLOADED_FUNCTION.
Make sure all trait method references are converted to absolute
method references in advance. This regresses one error message
that I don't think is particularly valuable.
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.
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.
This is equivalent to checking ce->num_interfaces. The only subtle
moment is during inheritance, where num_interface may change when
parent interfaces are inherited. The check in zend_do_link_class
thus uses "interfaces", not "ce->num_interfaces".
Always operate on copies of the functions, so we don't reference
temporary trait methods that have gone out of scope.
This could be more efficient, but doing an allocated copy only when
strictly necessary turned out to be somewhat tricky.
Any number of arguments can be replaced by a variadic one, so
long as the variadic argument is compatible (in the sense of
contravariance) with the subsumed arguments.
In particular this means that function(...$args) becomes a
near-universal signature: It is compatible with any function
signature that does not accept parameters by-reference.
This also fixes bug #70839, which describes a special case.
Closes GH-5059.
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.