Always memoize assert

Closes GH-11686

Fix double-compilation of arrow-function

We transform the arrow function by nesting the expression into a return
statement. If we compile the arrow function twice this would be done twic

Fix double-compilation of arrow-function

We transform the arrow function by nesting the expression into a return
statement. If we compile the arrow function twice this would be done twice,
leading to a compile assertion.

Fix oss-fuzz #60411
Closes GH-11632

show more ...

Add stack limit check in zend_eval_const_expr() (#11424)

Fix use-of-uninitialized-value with ??= on assert

Normally, PHP evaluates all expressions in offsets (property or array), as well
as the right hand side of assignments before actually fe

Fix use-of-uninitialized-value with ??= on assert

Normally, PHP evaluates all expressions in offsets (property or array), as well
as the right hand side of assignments before actually fetching the offsets. This
is well explained in this blog post.

https://www.npopov.com/2017/04/14/PHP-7-Virtual-machine.html#writes-and-memory-safety

For ??= we have a bit of a problem in that the rhs must only be evaluated if the
lhs is null or undefined. Thus, we have to first compile the lhs with BP_VAR_IS,
conditionally run the rhs and then re-fetch the lhs with BP_VAR_W to to make
sure the offsets are valid if they have been invalidated.

However, we don't want to just re-evaluate the entire lhs because it may contain
side-effects, as in $array[$x++] ??= 42;. In this case, we don't want to
re-evaluate $x++ because it would result in writing to a different offset than
was previously tested. The same goes for function calls, like
$array[foo()] ??= 42;, where the second call to foo() might result in a
different value. PHP behaves correctly in these cases. This is implemented by
memoizing sub-expressions in the lhs of ??= and reusing them when compiling the
lhs for the second time. This is done for any expression that isn't a variable,
i.e. anything that can (potentially) be written to.

Unfortunately, this also means that function calls are considered writable due
to their return-by-reference semantics, and will thus not be memoized. The
expression foo()['bar'] ??= 42; will invoke foo() twice. Even worse,
foo(bar()) ??= 42; will call both foo() and bar() twice, but
foo(bar() + 1) ??= 42; will only call foo() twice. This is likely not by design,
and was just overlooked in the implementation. The RFC does not specify how
function calls in the lhs of the coalesce assignment behaves. This should
probably be improved in the future.

Now, the problem this commit actually fixes is that ??= may memoize expressions
inside assert() function calls that may not actually execute. This is not only
an issue when using the VAR in the second expression (which would usually also
be skipped) but also when freeing the VAR. For this reason, it is not safe to
memoize assert() sub-expressions.

There are two possible solutions:

1. Don't memoize any sub-expressions of assert(), meaning they will execute
twice.
2. Throw a compile error.

Option 2 is not quite simple, because we can't disallow all memoization inside
assert(), as that would break assertions like assert($array[foo()] ??= 'bar');.
Code like this is highly unlikely (and dubious) but possible. In this case, we
would need to make sure that a memoized value could not be used across the
assert boundary it was created in. The complexity for this is not worthwhile. So
we opt for option 1 and disable memoization immediately inside assert().

Fixes GH-11580
Closes GH-11581

show more ...

Fix trailing if element JMP lineno

Having this lineno on the same last compiled element can lead to an incorrectly
covered line number.

if (true) {
if (false) {

Fix trailing if element JMP lineno

Having this lineno on the same last compiled element can lead to an incorrectly
covered line number.

if (true) {
if (false) {
echo 'Never executed';
}
} else {
}

The echo will be reported as covered because the JMP from the if (true) branch
to the end of the else branch has the same lineno as the echo.

This is lacking a test because zend_dump.c does not have access to
ctx->debug_level and I don't think it's worth adjusting all the cases.

Closes GH-11598

show more ...

RFC: Add #[Override] attribute (#9836)

* Add #[Override] attribute

* Move #[\Override] tests into Zend/tests/attributes/override/

* Check `check_only` before removing `ZEND

RFC: Add #[Override] attribute (#9836)

* Add #[Override] attribute

* Move #[\Override] tests into Zend/tests/attributes/override/

* Check `check_only` before removing `ZEND_ACC_OVERRIDE`

* NEWS/UPGRADING for #[\Override]

show more ...

Fix missing "Optional parameter before required" deprecation on union null type

The check would only work for the ?type syntax, but not type|null. Switch to a
check during type compilat

Fix missing "Optional parameter before required" deprecation on union null type

The check would only work for the ?type syntax, but not type|null. Switch to a
check during type compilation instead.

Fixes GH-11488
Closes GH-11497

show more ...

Fix mis-compilation of by-reference nullsafe operator

Fixes oss-fuzz #60011
Closes GH-11540

Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Co-authored-by: Niels Dossche <77

Fix mis-compilation of by-reference nullsafe operator

Fixes oss-fuzz #60011
Closes GH-11540

Co-authored-by: Dmitry Stogov <dmitry@zend.com>
Co-authored-by: Niels Dossche <7771979+nielsdos@users.noreply.github.com>

show more ...

Fix assertion violation for invalid class const objects in const expressions (#11458)

Fixes oss-fuzz #59764

More usage of known zend_str instead of C string (#11381)

Allow final modifier when using a method from a trait (#11394)

Fixes GH-11388.

Following https://wiki.php.net/rfc/horizontalreuse which introduced traits,
this should be allowed

Allow final modifier when using a method from a trait (#11394)

Fixes GH-11388.

Following https://wiki.php.net/rfc/horizontalreuse which introduced traits,
this should be allowed.
The implementation was refactored in 3f8c729. That commit is the first time
the "final" check appears AFAICT, but no reason was given for why. That
commit seems to have landed in 5.4.11 and the NEWS for that version doesn't
seem to mention something relevant to the behaviour change.
This patch removes the restriction of the final modifier.

Closes GH-11394.

show more ...

Revert "Use zend_ast_apply in zend_eval_const_expr (#11261)"

This reverts commit 1c733c8bbc295dbb0634371cc40952c1528f9038.

Fixes GH-11320

Allow arbitrary expressions in static variable initializer

Closes GH-9301

Use zend_ast_apply in zend_eval_const_expr (#11261)

Supporting new constant expressions requires remembering to add them to
zend_eval_const_expr, even if it only evalutes its children. T

Use zend_ast_apply in zend_eval_const_expr (#11261)

Supporting new constant expressions requires remembering to add them to
zend_eval_const_expr, even if it only evalutes its children. This is routinely
forgotten, at least by me. Use zend_ast_apply to solve this generically.

show more ...

Correctly handle multiple constants in typed declaration

While here also fix AST printing support.

Implement delayed early binding for classes without parents

Normally, we add classes without parents (and no interfaces or traits) directly
to the class map, early binding the class. How

Implement delayed early binding for classes without parents

Normally, we add classes without parents (and no interfaces or traits) directly
to the class map, early binding the class. However, if the same class has
already been registered, we would instead just add a ZEND_DECLARE_CLASS
instruction and let the handler throw a duplicate class declaration exception.

However, with opcache, if on the next request the files are included in the
opposite order, we won't perform early binding. To fix this, create a
ZEND_DECLARE_CLASS_DELAYED instruction instead and handle classes without
parents accordingly, skipping any linking for classes that are already linked in
delayed early binding.

Fixes GH-8846

show more ...

Allow aliasing namespaces containing reserved class names

This reverts commit b9f7123c5e4ccdc3c381ab949ff01e3c14f3465c.

Fixes GH-11152
Closes GH-11153

Typed class constants (#10444)

RFC: https://wiki.php.net/rfc/typed_class_constants

Co-Authored-By: Ben <7127204+moliata@users.noreply.github.com>
Co-Authored-By: Bob Weinand <31

Typed class constants (#10444)

RFC: https://wiki.php.net/rfc/typed_class_constants

Co-Authored-By: Ben <7127204+moliata@users.noreply.github.com>
Co-Authored-By: Bob Weinand <3154871+bwoebi@users.noreply.github.com>
Co-Authored-By: Ilija Tovilo <ilija.tovilo@me.com>

show more ...

Fix unevaluated rhs of class constant fetch in constant expression (#11047)

Fixes oss-fuzz #57821

Fix GH-8841: php-cli core dump calling a badly formed function

It's actually not php-cli specific, nor SAPI specific.
We should delay the registration of the function into the function t

Fix GH-8841: php-cli core dump calling a badly formed function

It's actually not php-cli specific, nor SAPI specific.
We should delay the registration of the function into the function table
until after the compilation was successful, otherwise the function is
mistakingly registered and a NULL dereference will happen when trying to
call it.

I based my test of Nikita's test, so credits to him for the test:
https://github.com/php/php-src/pull/8933#issuecomment-1259881008

Closes GH-10989.

show more ...

Use new ZSTR_INIT_LITERAL macro (#10879)

Fix GH-10570: Assertion `(key)->h != 0 && "Hash must be known"' failed.

Fixes GH-10570, see GH-10570 for analysis.

Closes GH-10572

zend_compiler, ...: use `uint8_t` instead of `zend_uchar` (#10621)

`zend_uchar` suggests that the value is an ASCII character, but here,
it's about very small integers. This is misleadi

zend_compiler, ...: use `uint8_t` instead of `zend_uchar` (#10621)

`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.

show more ...

Two `enum`s instead of preprocessor macros (#10617)

* Zend/zend_compile: convert `memoize_mode` macros to enum

* Zend/zend_stack: convert `ZEND_STACK_APPLY_*` macros to enum

Make various pointers const in Zend/ (#10608)

* Zend/zend_operators: pass const pointers to zend_is_identical()

* Zend/zend_operators: pass const pointers to zend_get_{long,double}(

Make various pointers const in Zend/ (#10608)

* Zend/zend_operators: pass const pointers to zend_is_identical()

* Zend/zend_operators: pass const pointers to zend_get_{long,double}()

* Zend/Optimizer/sccp: make pointers const

* Zend/Optimizer/scdf: make pointers const

* Zend/Optimizer/zend_worklist: make pointers const

* Zend/Optimizer/zend_optimizer: make pointers const

* Zend/zend_compile: make pointers const

show more ...