For FETCH_DIM_W etc encode the context it is being used in
(dim, obj, ref or incdec) so we can throw an appropriate error
message for invalid string offset use, in a way that does not
require inspecting neighboring opcodes. The implementation is
similar to the flags used for FETCH_OBJ.
This means that we do not have to be careful about preserving
following opcodes during optimization.
Closes GH-7599.
The immediate error here is the nested indexing in write context,
the fact that it's ultimately wrapped in an unset() doesn't matter.
Same as $str[0][0] += 1 will throw "Cannot use string offset as an
array", so should this case.
Even if the object property is incremented afterwards, the
immediate error is the use as object, not the increment.
Also consolidate tests for this error message. Previously they
were spread across a number of bug-specific tests.
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().
JIT contains a copy of this function that effectively only differs
by fetching current_execute_data from EG. We can do that in the VM
version as well, as this is just used to throw an error.
Export the VM function and reuse it in JIT.
Add additional zend_compile_position argument, which can be either
AT_SHEBANG, AT_OPEN_TAG or AFTER_OPEN_TAG. The previous behavior
corresponds to AFTER_OPEN_TAG.
Closes GH-7462.
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.
Currently, resource IDs are limited to 32-bits. As resource IDs
are not reused, this means that resource ID overflow for
long-running processes is very possible.
This patch switches resource IDs to use zend_long instead, which
means that on 64-bit systems, 64-bit resource IDs will be used.
This makes resource ID overflow practically impossible.
The tradeoff is an 8 byte increase in zend_resource size.
Closes GH-7436.
Currently, CE_CACHE on strings is only used with opcache interned strings. This
patch extends usage to non-opcache interned strings as well. This means that
most type strings can now make use of CE_CACHE even if opcache is not loaded,
which allows us to remove TYPE_HAS_CE kind, and fix some discrepancies
depending on whether a type stores a resolved or non-resolved name.
There are two cases where CE_CACHE will not be used:
* When opcache is not used and a permanent interned string (that is not an
internal class name) is used as a type name during the request. In this case
we can't allocate a map_ptr index for the permanent string, as it would be
not be in the permanent map_ptr index space.
* When opcache is used but the script is not cached (e.g. eval'd code or
opcache full). If opcache is used, we can't allocate additional map_ptr
indexes at runtime, because they may conflict with indexes allocated by
opcache.
In these two cases we would end up not using CE caching for property types
(argument/return types still have the separate cache slot).
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>
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.
