Now that operator errors are detected more accurately, we no longer
have any cases where we throw a compile-time error instead of a
run-time exception, so we can drop this check now.
For division (rather than modulus) we should check the double
value, otherwise the result might be zero after integer truncation,
but not zero as a floating point value.
Instead of looping, use straight-line code with the following
layout:
1. Try to apply the base operation on the dereferenced operands.
2. Try overloaded object operations.
3. Try to convert operands to number, else error out.
4. Apply the base operation on the converted operands.
This makes the code easier to reason about and fixes some edge-case
bugs:
1. We should only try invoking operator overloading once prior to
type conversion. Previously it was invoked both before and after
type conversion.
2. We should not modify any values if an exception is thrown.
Previously we sometimes modified the LHS of a compound assignment
operator.
3. If conversion of the first operand fails, we no longer try to
convert the second operand. I think the previous behavior here
was fine as well, but this still seems a more typical.
This will also make some followup changes I have in mind simpler.
Avoid subtle differences in behavior depending on whether the
handler is absent or returns FAILURE.
If you previously set cast_object to NULL, create a handler that
always returns FAILURE instead.
To explicitly indicate that objects are uncomparable. For now
this has no functional difference from the usual 1 return value,
but makes intent clearer.
Make cast_object return FAILURE for casts to int/float, rather than
throwing a notice and returning SUCCESS. Instead move the emission
of the notice to the code invoking cast_object. This will allow us
to customize the behavior per call-site.
This change is written to be NFC, and the code in
zend_std_compare_objects() should illustrate the current behavior
doesn't make a lot of sense.
This reverts commit bb43a3822e.
After thinking about this a bit more, this is now going to be
a complete solution for the "readonly properties" case, for example:
unset($foo->readOnly->bar);
should also be legal and
$foo->readOnly['bar'] = 42;
should also be legal if $foo->readOnly is not an array but an
ArrayAccess object.
I think it may be better to distinguish better on the BP_VAR flag
level. Reverting for now.
$a->b->c = 'd';
is now compiled the same way as
$b = $a->b;
$b->c = 'd';
That is, we perform a read fetch on $a->b, rather than a write
fetch.
This is possible, because PHP 8 removed auto-vivification support
for objects, so $a->b->c = 'd' may no longer modify $a->b proper
(i.e. not counting interior mutability of the object).
Closes GH-5250.
* PHP-7.4:
Check asserts early
identation fix
Call global code of preloaded script in global context
Avoid "Anonymous class wasn't preloaded" error by lazely loading of not preloaded part of a preloaded script
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.
