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.
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
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
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
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
* PHP-8.1:
Fix GH-10990: mail() throws TypeError after iterating over $additional_headers array by reference
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.
For early observing, there already exists a op_array_ctor hook on zend_extension.
However the goal of the declared_function observer is noting the time when a fully defined function starts existing in the function_tables.
This also prevents the observer being called in case there were compilation errors.
Ultimately, this now gives a consistent behaviour with respect to how it works when opcache is enabled:
- pass_two is done, opcodes and flags are all finalized.
- similarly class_linked notifications also only happen once the class is actually finalized.
- any extension wanting to delay the observer call may add the ZEND_COMPILE_IGNORE_OBSERVER compiler_option, then call it itself.
The intersection type needs to be marked as being allocated on the arena otherwise zend_persist_type() tries to free it and corrupts the Zend MM Heap
Also we only need to allocate the space for a list of size 1 and not the whole length of the intersection type
The issue was that we didn't compute enough cache slots for DNF types.
Nor progressed throught the CE's in the cache slot, meaning we were only checking if the value passed
satisfied the first type of the nested intersection type.
Object handlers being separate from class entries is a legacy inherited from PHP 5. Today it has little benefit to keep them separate: in fact, accessing object handlers usually requires not-so-safe hacks.
While it is possible to swap handlers in a custom installed create_object handler, this mostly is tedious, as well as it requires allocating the object handlers struct at runtime, possibly caching it etc..
This allows extensions, which intend to observe other classes to install their own class handlers.
The life cycle of internal classes may now be simply observed by swapping the class handlers in post_startup stage.
The life cycle of userland classes may be observed by iterating over the new classes in zend_compile_file and zend_compile_string and then swapping their handlers.
In general, this would also be a first step in directly tying the object handlers to classes. Especially given that I am not aware of any case where the object handlers would be different between various instances of a given class.
Signed-off-by: Bob Weinand <bobwei9@hotmail.com>
If one tries to use such an alias as a type declaration the following error would be raised:
Fatal error: Cannot use 'int' as class name as it is reserved
The ast node flag constants ZEND_DIM_ALTERNATIVE_SYNTAX and
ZEND_ENCAPS_VAR_DOLLAR_CURLY_VAR_VAR node have identical values (1<<1),
causing a deprecation notice to be incorrectly emitted before the fatal error
for unsupported syntax.
Fixes GH-9263
Explicitly check for AST_VAR/AST_DIM kind for future compatibility
`AST_PROP`/`AST_METHOD_CALL` and nullsafe variants can also be found in
encapsulated strings - currently they have no flags but they may have flags in
the future. This also clarifies that this deprecation warning can only happen
for AST_VAR/AST_DIM nodes for certain `attr` values.
