Revision tags: php-8.0.0, php-7.3.25, php-7.4.13, php-8.0.0RC5, php-7.4.13RC1, php-8.0.0RC4, php-7.3.25RC1, php-7.4.12, php-8.0.0RC3, php-7.3.24, php-8.0.0RC2, php-7.4.12RC1, php-7.3.24RC1, php-7.2.34, php-8.0.0rc1, php-7.4.11, php-7.3.23, php-8.0.0beta4, php-7.4.11RC1, php-7.3.23RC1, php-8.0.0beta3, php-7.4.10, php-7.3.22, php-8.0.0beta2, php-7.3.22RC1, php-7.4.10RC1, php-8.0.0beta1, php-7.4.9, php-7.2.33, php-7.3.21, php-8.0.0alpha3, php-7.4.9RC1, php-7.3.21RC1, php-7.4.8, php-7.2.32, php-8.0.0alpha2, php-7.3.20, php-8.0.0alpha1, php-7.4.8RC1, php-7.3.20RC1, php-7.4.7, php-7.3.19 |
|
#
d30cd7d7 |
| 26-May-2020 |
Máté Kocsis |
Review the usage of apostrophes in error messages Closes GH-5590
|
Revision tags: php-7.4.7RC1, php-7.3.19RC1, php-7.4.6, php-7.2.31, php-7.4.6RC1, php-7.3.18RC1 |
|
#
1179686f |
| 24-Apr-2020 |
Máté Kocsis |
Improve error messages for invalid property access Closes GH-5446 Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>
|
Revision tags: php-7.2.30, php-7.4.5, php-7.3.17, php-7.4.5RC1, php-7.3.17RC1 |
|
#
36935e42 |
| 30-Mar-2020 |
Máté Kocsis |
Improve undefined variable error messages Closes GH-5312
|
#
df79277d |
| 18-Mar-2020 |
Nikita Popov |
Revert "Fetch for read in nested property assignments" This reverts commit bb43a3822e42dbd15b1d416a166549d3980b379a. After thinking about this a bit more, this is now going to be
Revert "Fetch for read in nested property assignments" This reverts commit bb43a3822e42dbd15b1d416a166549d3980b379a. 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.
show more ...
|
Revision tags: php-7.3.18, php-7.4.4, php-7.2.29, php-7.3.16 |
|
#
bb43a382 |
| 10-Mar-2020 |
Nikita Popov |
Fetch for read in nested property assignments $a->b->c = 'd'; is now compiled the same way as $b = $a->b; $b->c = 'd'; That is, we perform a read f
Fetch for read in nested property assignments $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.
show more ...
|
Revision tags: php-7.4.4RC1, php-7.3.16RC1, php-7.4.3, php-7.2.28, php-7.3.15RC1, php-7.4.3RC1, php-7.3.15, php-7.2.27, php-7.4.2, php-7.3.14, php-7.3.14RC1, php-7.4.2RC1, php-7.4.1, php-7.2.26, php-7.3.13, php-7.4.1RC1, php-7.3.13RC1, php-7.2.26RC1, php-7.4.0, php-7.2.25, php-7.3.12, php-7.4.0RC6, php-7.3.12RC1, php-7.2.25RC1, php-7.4.0RC5, php-7.1.33, php-7.2.24, php-7.3.11, php-7.4.0RC4, php-7.3.11RC1, php-7.2.24RC1 |
|
#
2f92957f |
| 01-Oct-2019 |
Nikita Popov |
Convert some notices to warnings Part of https://wiki.php.net/rfc/engine_warnings.
|
Revision tags: php-7.4.0RC3 |
|
#
a66c60cc |
| 26-Sep-2019 |
Nikita Popov |
Throw Error when writing property of non-object This removes object auto-vivification support. This also means that we can remove the corresponding special handling for typed pr
Throw Error when writing property of non-object 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.
show more ...
|
Revision tags: php-7.2.23, php-7.3.10, php-7.4.0RC2, php-7.2.23RC1, php-7.3.10RC1, php-7.4.0RC1, php-7.1.32, php-7.2.22, php-7.3.9, php-7.4.0beta4, php-7.2.22RC1, php-7.3.9RC1, php-7.4.0beta2, php-7.1.31, php-7.2.21, php-7.3.8, php-7.4.0beta1, php-7.2.21RC1, php-7.3.8RC1, php-7.4.0alpha3, php-7.3.7, php-7.2.20, php-7.4.0alpha2, php-7.3.7RC3, php-7.3.7RC2, php-7.2.20RC2, php-7.4.0alpha1, php-7.3.7RC1, php-7.2.20RC1, php-7.2.19, php-7.3.6, php-7.1.30, php-7.2.19RC1, php-7.3.6RC1, php-7.1.29, php-7.2.18, php-7.3.5, php-7.2.18RC1, php-7.3.5RC1, php-7.2.17, php-7.3.4, php-7.1.28, php-7.3.4RC1, php-7.2.17RC1, php-7.1.27, php-7.3.3, php-7.2.16, php-7.3.3RC1, php-7.2.16RC1, php-7.2.15, php-7.3.2, php-7.2.15RC1, php-7.3.2RC1, php-5.6.40, php-7.1.26, php-7.3.1, php-7.2.14, php-7.2.14RC1, php-7.3.1RC1, php-5.6.39, php-7.1.25, php-7.2.13, php-7.0.33, php-7.3.0, php-7.1.25RC1, php-7.2.13RC1, php-7.3.0RC6, php-7.1.24, php-7.2.12, php-7.3.0RC5, php-7.1.24RC1, php-7.2.12RC1, php-7.3.0RC4, php-7.1.23, php-7.2.11, php-7.3.0RC3, php-7.1.23RC1, php-7.2.11RC1, php-7.3.0RC2, php-5.6.38, php-7.1.22, php-7.3.0RC1, php-7.2.10, php-7.0.32, php-7.1.22RC1, php-7.3.0beta3, php-7.2.10RC1, php-7.1.21, php-7.2.9, php-7.3.0beta2, php-7.1.21RC1, php-7.3.0beta1, php-7.2.9RC1, php-5.6.37, php-7.1.20, php-7.3.0alpha4, php-7.0.31, php-7.2.8, php-7.1.20RC1, php-7.2.8RC1, php-7.3.0alpha3, php-7.3.0alpha2, php-7.1.19, php-7.2.7, php-7.1.19RC1, php-7.3.0alpha1, php-7.2.7RC1, php-7.1.18, php-7.2.6, php-7.2.6RC1, php-7.1.18RC1, php-5.6.36, php-7.2.5, php-7.1.17, php-7.0.30, php-7.1.17RC1, php-7.2.5RC1, php-5.6.35, php-7.0.29, php-7.2.4, php-7.1.16, php-7.1.16RC1, php-7.2.4RC1, php-7.1.15, php-5.6.34, php-7.2.3, php-7.0.28 |
|
#
e63febb1 |
| 15-Feb-2018 |
David Walker |
Fixed bug #75921 Ensure that the "creating default object from empty value" warning is always thrown. Previously some cases were missing the warning, in particular those going throug
Fixed bug #75921 Ensure that the "creating default object from empty value" warning is always thrown. Previously some cases were missing the warning, in particular those going through FETCH_OBJ_W rather than a dedicated opcode (like ASSIGN_OBJ). One slightly unfortunate side-effect of this change is that something like $a->b->c = 'd' will now generate two warnings rather than one when $a is null (one for property b, one for property c).
show more ...
|