When redeclaring an overridden static property with a trait we're removing the
property from the class. However, because the property itself does not belong to
the class we must not free its associated data.
This issue is exposed by 9a250cc9d6 in PHP 8.3+ because duplicate static
properties in traits are no longer skipped, but redeclared.
Fixes GH-12468
This currently uses ZVAL_COPY_OR_DUP, which copies the value and handles
refcounting. However, internal classes cannot have refcounted default
properties because of constraints imposed by
zend_declare_typed_property(). So copying the value is sufficient.
While this doesn't really improve the performance for our benchmarks, it
improves performance for cases where a lot of temporary internal objects
are instantiated. For example, when instantiating DOM classes: DOM
objects are transient, so lots of temporary objects are created.
* Make sure core module has number 0
Some places, possibly also outside PHP, assume the core extension has
module number 0. After 8a812c3fda this wasn't the case anymore as
reported in [1]. Fix it by changing how the next module ID is computed.
[1] https://github.com/php/php-src/pull/12246#issuecomment-1731432377
* Add assertion
* Add test
When we try to load an extension multiple times, we still overwrite the
type, module number, and handle. If the module number is used to
indicate module boundaries (e.g. in reflection and in dom, see e.g.
dom_objects_set_class_ex), then all sorts of errors can happen.
In the case of ext/dom, OP's error happens because the following
happens:
- The property handler is set up incorrectly in
dom_objects_set_class_ex() because the wrong module number is
specified. The class highest in the hierarchy is DOMNode, so the
property handler is incorrectly set to that of DOMNode instead of
DOMDocument.
- The documentElement property doesn't exist on DOMNode, it only exists
on DOMDocument, so it tries to read using zend_std_read_property().
As there is no user property called documentElement, that read
operation returns an undef value.
However, the type is still checked, resulting in the strange exception.
Solve this by changing the API such that the data is only overwritten if
it's owned data.
Closes GH-12246.
When declaring the same static property with a doc block in a class and in a trait,
the doc block of the property in the class is leaked. While at it, possibly fix doc
comment for internal classes.
Close GH-12238
This PR introduces a new way of recursion protection in JSON, var_dump
and friends. It fixes issue in master for __debugInfo and also improves
perf for jsonSerializable in some cases. More info can be found in
GH-10020.
Closes GH-11812
This merges all usages of emitting an offset TypeError into a new ZEND_API function
zend_illegal_container_offset(const zend_string* container, const zval *offset, int type);
Where the container should represent the type on which the access is attempted (e.g. string, array)
The offset zval that is used, where the error message will display its type
The type of access, which should be a BP_VAR_* constant, to get special message for isset/empty/unset
`zend_rc_debug` is not a type and does not really belong in
`zend_types.h`; this allows using `ZEND_RC_MOD_CHECK()` without
including the huge `zend_types.h` header and allows decoupling
circular header dependencies.
* Remove always-false check in zend_lookup_class_ex()
This check is always false because of the undefined behaviour rule that
says a NULL pointer must never be dereferenced: we already dereference name
when checking the cache slot, before the NULL check. So the NULL may be
optimised away by the compiler. It looks like the code isn't even
supposed to work with name being NULL, so just remove the check.
* Remove always-true check in zend_fetch_static_property_address_ex()
* Simplify always-true conditions
zend_update_static_property_ex() returns a zend_result, but the return
value is stored here in a bool. A bool is unsigned on my system, so in
case zend_update_static_property_ex() returns FAILURE (== -1) this gets
converted to 1 instead. This is not a valid zend_result value. This
means that (transitive) callers could mistakingly think the function
succeeded while it did in fact not succeed. Fix it by changing the type
to zend_result.
Closes GH-10691.
`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleading, so let's use a
C99 integer instead.
On all architectures currently supported by PHP, `zend_uchar` and
`uint8_t` are identical. This change is only about code readability.
We can't increase the refcount of internal classes during request time.
To work around this problem we simply don't refcount aliases anymore and
add a check in the destruction to skip aliases entirely.
There were also some checks which checked for an alias implicitly by
comparing the refcount, these have been replaced by checking the type of
the zval instead.
This corrects the paren placement to the intended one.
As these functions use zend_result, the success value is zero. Therefore
this has no functional change. The only difference is that this now
hints the compiler optimizer correctly.
Closes GH-10364.
* Emit deprecation warnings when adding dynamic properties to classes during unserialization - this will become an Error in php 9.0.
(Adding dynamic properties in other contexts was already a deprecation warning - the use case of unserialization was overlooked)
* Throw an error when attempting to add a dynamic property to a `readonly` class when unserializing
* Add new serialization methods `__serialize`/`__unserialize` for SplFixedArray to avoid creating deprecated dynamic
properties that would then be added to the backing fixed-size array
* Don't add named dynamic/declared properties (e.g. $obj->foo) of SplFixedArray to the backing array when unserializing
* Update tests to declare properties or to expect the deprecation warning
* Add news entry
Co-authored-by: Tyson Andre <tysonandre775@hotmail.com>
