Factor out common check for short-circuited ast

Fix OSS-Fuzz #69765: Yield reference to nullsafe chain

You cannot return or yield a reference to a nullsafe chain. This was
checked already in zend_compile_return but not yet in
zend

Fix OSS-Fuzz #69765: Yield reference to nullsafe chain

You cannot return or yield a reference to a nullsafe chain. This was
checked already in zend_compile_return but not yet in
zend_compile_yield.

Closes GH-14716.

show more ...

Add missing COMPILE_IGNORE_OTHER_FILES check for static calls

Closes GH-13986

WS

Clarify the stack limit exception message

Make it clearer why the size is not exactly zend.max_allowed_stack_size

Fix invalid returned opcode for memoized expressions

Closes GH-12345

Improve invalid cpp modifier message

The ZEND_MODIFIER_TARGET_CPP should really have been called _PARAM, but we
shouldn't break API at this point.

Fixes GH-12069
Closes GH-1

Improve invalid cpp modifier message

The ZEND_MODIFIER_TARGET_CPP should really have been called _PARAM, but we
shouldn't break API at this point.

Fixes GH-12069
Closes GH-12175

show more ...

Fix zend_separate_if_call_and_write for FUNC_ARGs

Fixes GH-12102
Closees GH-12140

Use a single version of strnlen (#12015)

* Zend: Make zend_strnlen available for use outside zend_compile

* exif: remove local php_strnlen, use zend_strnlen instead

* main

Use a single version of strnlen (#12015)

* Zend: Make zend_strnlen available for use outside zend_compile

* exif: remove local php_strnlen, use zend_strnlen instead

* main: remove local strnlen, use zend_strnlen instead

* phar: remove local strnlen, use zend_strnlen

show more ...

Adds support for DNF types in internal functions and properties (#11969)

Note that this does not add support for items generated by gen_stubs,
only for items registered dynamically via

Adds support for DNF types in internal functions and properties (#11969)

Note that this does not add support for items generated by gen_stubs,
only for items registered dynamically via the Zend API.

Closes GH-10120

show more ...

Remove redundant condition

Never refactor code just before pushing

Fix segfault in format_default_value due to unexpected enum/object

Evaluating constants at comptime can result in arrays that contain objects. This
is problematic for printing the defaul

Fix segfault in format_default_value due to unexpected enum/object

Evaluating constants at comptime can result in arrays that contain objects. This
is problematic for printing the default value of constant ASTs containing
objects, because we don't actually know what the constructor arguments were.
Avoid this by not propagating array constants.

Fixes GH-11937
Closes GH-11947

show more ...

Move opnum_start for goto for clarification (#11911)

opnum_start denotes the start of the ZEND_FREE block of skipped consuming
opcodes. Storing the number before zend_compile_expr(..., l

Move opnum_start for goto for clarification (#11911)

opnum_start denotes the start of the ZEND_FREE block of skipped consuming
opcodes. Storing the number before zend_compile_expr(..., label_ast) makes it
seem like it denotes the start of the label block. However, label_ast must only
be a zval string AST, and as such never results in an actual opcode.

show more ...

Always memoize calls in lhs of coalesce assignment

We don't want to invoke calls twice, even if they are considered "variables",
i.e. might be writable if returning a reference. Function

Always memoize calls in lhs of coalesce assignment

We don't want to invoke calls twice, even if they are considered "variables",
i.e. might be writable if returning a reference. Function calls behave the same
in all BP contexts so they don't need to be invoked twice. The singular
exception to this is nullsafe coalesce in isset/empty, because it needs to
return false/true respectively when short-circuited. However, since nullsafe
calls are not allwed in write context we may ignore this problem.

Closes GH-11592

show more ...

Add support for deprecating class constants

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)