FREE_OP_VAR_PTR() is like FREE_OP(), but only frees VAR, rather
than VARs and TMPs. I don't think this distinction makes sense
anymore, as opcodes using FREE_OP_VAR_PTR() generally only accept
VAR or CV. For the cases where other op types are accepted and
only freeing VAR is desired we already have FREE_OP_IF_VAR().
This drops FREE_OP_VAR_PTR(), leaving only FREE_OP() and
FREE_OP_IF_VAR().
Set the variable to null after emitting the undef var notice
rather than before. This avoids an assertion failure if the var
is unset by the error handler.
The flip side is that this may cause a leak instead, but that's
the more harmless outcome.
Fixes oss-fuzz #36604.
Even if we can't actually pass by reference, we still need to
create the REFERENCE wrapper to satisfy the calling convention.
The particular test case would crash with JIT, because the existence
of the reference was assumed.
Fixes oss-fuzz #39440.
Even though the input is not a reference (or not treated as such),
we still need to create a reference to satisfy the function
signature. Various code relies on reference arguments actually
being references. In this particular case, it would result in
a JIT crash.
The zend_call_function() implementation already handled this
correctly.
This issue only applies to debug builds: read_property can free
the object, but we'd try to check the object handlers afterwards.
Rewrite the check in a way that only accessed the object before
the read_property call.
Fixes oss-fuzz #38297.
We must avoid integer overflows in memory allocations, so we introduce
an additional check in the VM, and bail out in the rare case of an
overflow.
Closes GH-7381.
The reference wrapper was destroyed while value still pointed into
it and was later used to assign the ASSIGN_DIM return value. This
could be fixed either by moving the return value assignment earlier,
or by working with the value that has been stored in the array.
I'm going with the latter here, because that matches what the
non-NEXT codepath does via assign_to_variable more closely.
Fixes oss-fuzz #36807.
Currently, classes that can't be linked get moved back into the original script
and are not preloaded. As such classes may be referenced from functions that
did get preloaded, there is a preload autoload mechanism to load them at
runtime.
Since PHP 8.1, we can safely preload unlinked classes, which will then go
through usual lazy loading. This means that we no longer need the preload
autoload mechanism. However, we need to be careful not to modify any hash
table buckets in-place, and should create new buckets for lazy loaded classes.
Convert zend_hash_find_ex(..., 1) to zend_hash_find_known_hash(...)
Convert zend_hash_find_ex(..., 0) to zend_hash_find(...)
Also add serializable changes to UPGRADING.INTERNALS summary
Add support for readonly properties, for which only a single
initializing assignment from the declaring scope is allowed.
RFC: https://wiki.php.net/rfc/readonly_properties_v2
Closes GH-7089.
Deprecate automatically converting "false" into an empty array
on write operands. Autovivification continues to be supported
for "null" values, as well as undefined/uninitialized values.
RFC: https://wiki.php.net/rfc/autovivification_false
Closes GH-7131.
Co-authored-by: Tyson Andre <tysonandre775@hotmail.com>
Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
For a particular assignment, a non-coerced constant assignment
value will remain valid. However, opcache merges cache slots for
all identical property references, which means that this
optimization also disables property type checks for all other
operands on the property that occur in the same functions.
This could be addressed by blocking cache slot merging in opcache,
but I prefer dropping it entirely instead. It does not seem
important enough to warrant doing that.
Support acquiring a Closure to a callable using the syntax
func(...), $obj->method(...), etc. This is essentially a
shortcut for Closure::fromCallable().
RFC: https://wiki.php.net/rfc/first_class_callable_syntax
Closes GH-7019.
Co-Authored-By: Nikita Popov <nikita.ppv@gmail.com>
Static trait members may only be accessed through a class in which
the trait is used, not directly on the trait.
A complication here is that we should not store static
methods/properties for which a deprecation is triggered in a
cache slot. As the check for this is simple and cheap, I'm handling
this in the cache slot population code in the VM. The alternative
would be to pass the cache slot down into the fetching code.
Part of https://wiki.php.net/rfc/deprecations_php_8_1.
