Avoid need of insertion NOP opcoes between unrelated SMART BRANCH instruction and following JMPZ/JMPNZ.
Now instead of checking the opcode of following instruction, the same information is encoded into SMART BRANH result_type.
Previously if the "non well formed" notice was converted into an
exception we'd still end up executing the function.
Also drop the now unnecessary EG(exception) checks in the engine.
Additionally remote a bogus exception in zend_is_callable: It
should only be writing to error, but not directly throwing.
Make sure the initialize the result of FETCH_OBJ_UNSET operations.
I'm using a NULL value rather than ERROR here, because the latter
no longer exists in master.
It is now only used to signal exceptions for property reads. ERROR
zvals are never returned back to the VM anymore, so there's no
need to check for them when receiving a VAR.
Also return MAY_BE_ERROR, as ERROR is now no longer relevant for
inference.
This removes object auto-vivification support.
This also means that we can remove the corresponding special
handling for typed properites: We no longer need to check that a
property is convertible to stdClass if such a conversion might
take place indirectly due to a nested property write.
Additionally OBJ_W style operations now no longer modify the
object operand, and as such we no longer need to treat op1 as a
def in SSA form.
The next step would be to actually compile the whole LHS of OBJ_W
operations in R rather than W mode, but that causes issues with
SimpleXML, whose object handlers depend on the current compilation
structure.
Part of https://wiki.php.net/rfc/engine_warnings.
`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.
We have lots of other typed properties related error messages of
the form "assign X to typed property Y::$z of type A", so use th
same format for the primary message as well. Special-casing things
like classes and nullability is not going to scale with future
type-system extensions, and I don't think it really adds clarity
either.
This switches zend_type from storing a single IS_* type code to
storing a MAY_BE_* type mask. Right now most code still assumes
that there is only a single type in the mask (or two together
with MAY_BE_NULL). But this will make it a lot simpler to introduce
union types.
An additional advantage (and why I'm doing this separately), is
that a number of special cases no longer need to be handled
separately: We can do a single mask & (1 << type) check to handle
all simple types, booleans (true|false) and null.
Instead of checking for this during DO_FCALL, already detect this
case during get_method()/get_static_method(), similar to visibility
checks.
This causes a minor difference in behavior, in that arguments will
no longer be evaluated. I think this is correct though (and consistent
with visibility errors).
The exception mechanism assumes that exceptions from DO_FCALL are
already happening after the function call. This means that we are
currently leaking the passed arguments, and I think we can also
corrupt the VM stack due to incorrect frame linking in some cases
(there are assertion failures if the VM stack page size is reduced).
Instead handle the stack frame freeing manually for this special
case.
The returned value must match the specified type exactly, as we
can't perform any coercions in non-debug builds.
Fix incorrect stub for easter_date() that slipped through the
assertion for this reason...
By avoiding unused variable opline warnings. Also clean up the
replacement of ZEND_VM_SPEC -- we were sometimes treating it as
an always-defined constant with a value (what it actually is) and
sometimes as a conditionally defined constant (which it isn't, but
which still worked thanks to the specializer). Switch to only
treating it as a constant with a value.
No notice is thrown for list() accesses, because we did not come
to an agreement regarding patterns like
while ([$key, $value] = yield $it->next()) { ... }
where silent null access may be desirable.
No effort is made to suppress multiple notices in access chains
likes $x[0][0][0], because the technical complexity this causes
does not seem worthwhile.
RFC: https://wiki.php.net/rfc/notice-for-non-valid-array-container
