Allow arbitrary expressions in static variable initializer

Closes GH-9301

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

Implement dynamic class const fetch

https://wiki.php.net/rfc/dynamic_class_constant_fetch

Closes GH-9793

Merge branch 'PHP-8.1'

* PHP-8.1:
Fix memory leak

Merge branch 'PHP-8.0' into PHP-8.1

* PHP-8.0:
Fix memory leak

Fix memory leak

Fixes oss-fuzz #44222

Remove JMPZNZ opcode

While JMPZNZ can avoid execution of a separate JMP opcode in some
cases, it also prevents smart branch optimization, so creating
JMPZNZ may actually have a negat

Remove JMPZNZ opcode

While JMPZNZ can avoid execution of a separate JMP opcode in some
cases, it also prevents smart branch optimization, so creating
JMPZNZ may actually have a negative effect. It also adds additional
complexity for optimizations.

Drop JMPZNZ in favor of JMPZ+JMP or JMPNZ+JMP.

Closes GH-7857.

show more ...

Handle holes in zend_get_opcode_id()

Some opcodes may currently not be allocated.

Add first-class callables

Support acquiring a Closure to a callable using the syntax
func(...), $obj->method(...), etc. This is essentially a
shortcut for Closure::fromCallable().

Add first-class callables

Support acquiring a Closure to a callable using the syntax
func(...), $obj->method(...), etc. This is essentially a
shortcut for Closure::fromCallable().

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

Closes GH-7019.

Co-Authored-By: Nikita Popov <nikita.ppv@gmail.com>

show more ...

Implement never return type

The never type can be used to indicate that a function never
returns, for example because it always unwinds.

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

Implement never return type

The never type can be used to indicate that a function never
returns, for example because it always unwinds.

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

Closes GH-6761.

show more ...

Add zend_get_opcode_id() to get opcode id from name

Reference dynamic functions through dynamic_defs

Currently, dynamically declared functions and closures are inserted
into the function table under a runtime definition key, and then late

Reference dynamic functions through dynamic_defs

Currently, dynamically declared functions and closures are inserted
into the function table under a runtime definition key, and then later
possibly renamed. When opcache is not used and a file containing a
closure is repeatedly included, this leads to a very large memory leak,
as the no longer needed closure declarations will never be freed
(https://bugs.php.net/bug.php?id=76982).

With this patch, dynamic functions are instead stored in a
dynamic_func_defs member on the op_array, which opcodes reference
by index. When the parent op_array is destroyed, the dynamic_func_defs
it contains are also destroyed (unless they are stilled used elsewhere,
e.g. because they have been bound, or are used by a live closure). This
resolves the fundamental part of the leak, though doesn't completely
fix it yet due to some arena allocations.

The main non-obvious change here is to static variable handling:
We can't destroy static_variables_ptr in destroy_op_array, as e.g.
that would clear the static variables in a dynamic function when
the op_array containing it is destroyed. Static variable destruction
is separated out for this reason (we already do static variable
destruction separately for normal functions, so we only need to
handle main scripts).

Closes GH-5595.

show more ...

Restrict allowed usages of $GLOBALS

This restricts allowed usage of $GLOBALS, with the effect that
plain PHP arrays can no longer contain INDIRECT elements.

RFC: https://wiki.ph

Restrict allowed usages of $GLOBALS

This restricts allowed usage of $GLOBALS, with the effect that
plain PHP arrays can no longer contain INDIRECT elements.

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

Closes GH-6487.

show more ...

Implement named parameters

From an engine perspective, named parameters mainly add three
concepts:

* The SEND_* opcodes now accept a CONST op2, which is the
argument nam

Implement named parameters

From an engine perspective, named parameters mainly add three
concepts:

* The SEND_* opcodes now accept a CONST op2, which is the
argument name. For now, it is looked up by linear scan and
runtime cached.
* This may leave UNDEF arguments on the stack. To avoid having
to deal with them in other places, a CHECK_UNDEF_ARGS opcode
is used to either replace them with defaults, or error.
* For variadic functions, EX(extra_named_params) are collected
and need to be freed based on ZEND_CALL_HAS_EXTRA_NAMED_PARAMS.

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

Closes GH-5357.

show more ...

Implement nullsafe ?-> operator

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

Closes GH-5619.

Co-authored-by: Nikita Popov <nikita.ppv@gmail.com>

Implement match expression

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

Closes GH-5371.

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

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

Add support for $obj::class

This allows $obj::class, which gives the same result as get_class($obj).
Anything other than an object results in TypeError.

RFC: https://wiki.php.ne

Add support for $obj::class

This allows $obj::class, which gives the same result as get_class($obj).
Anything other than an object results in TypeError.

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

Closes GH-5065.

show more ...

Inline hot parts of bitwise instructions into hybrid VM

Actually remove the YIELD key specialization

I only adjusted the code before, without switching to TMPVAR.

Reduce YIELD_FROM specialization

Generator delegation is a complex compound operation, it does not
make a lot of sense to optimize refcounting here to this degree.

Reduce ZEND_THROW specialization

Throwing is very expensive due to the need of gathering the backtrace,
so it makes little sense to optimize refcounting to this degree.

Change ZEND_RECV and ZEND_RECV_VARIADIC to use extended_value for cache slot (instead of op2), to be consistent with ZEND_RECV_INIT.

Avoid over-specialization