Fixed destruction of objects and iterators on unclean request shutdown and GC (few cases are still unfixed).
Now we destroy objects it two steps. At first - object properties of all objects and o

Fixed destruction of objects and iterators on unclean request shutdown and GC (few cases are still unfixed).
Now we destroy objects it two steps. At first - object properties of all objects and only then the objects their selves.

show more ...

Refactored data structures to keep zend_object* instead of a whole zval in some places

Iterator has to be properly closed

Refactored GC (incomplete)

Refactored EG(active_symbol_table) to be zend_array* instead of HashTable*

Fixed Generator::throw()

Revert "Move zend_objects_store_put out of zend_object_std_init"

This reverts commit 8ced4f0ac906fd9a28b968801487630326c45bc8.

Move zend_objects_store_put out of zend_object_std_init

Various fixes related to read_property(), read_dimension() and iterators refactoring

Refactoring zend_iterator (incompleted)

Fixed iterators API. zend_iterator_init() has to be used in each get_iterator() callback.

Generator related fixes

Use better data structures (incomplete)

Use better data structures (incomplete) - refactored return_value handling

Use better data structures (incomplete)

Bump year

Bump year

Fix bug #65764

I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yi

Fix bug #65764

I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yield expression) should first advance to
the first yield and throw the exception there or whether it should
instead throw the exception in the caller's context.

The old behavior was to throw it at the start of the function (i.e.
the very first opcode), which causes issues like the one in #65764.
Effectively it's impossible to properly handle the exceptions in this
case.

For now I choose the variant where the generator advances to the
first yield before throwing, as that's consistent with how all other
methods on the Generator object currently behave. This does not
necessarily match the behavior in other languages, e.g. Python would throw
the exception in the caller's context. But then our send() method already
has this kind of deviation, so it stays internally consistent at least.

show more ...

Cleanup generator closing code a bit

All code dealing with unfinished execution cleanup is now in a separate
function (previously most of it was run even when execution was properly

Cleanup generator closing code a bit

All code dealing with unfinished execution cleanup is now in a separate
function (previously most of it was run even when execution was properly
finished.

Furthermore some code dealing with unclean shutdowns has been removed,
which is no longer necessary, because we no longer try to clean up in
this case.

show more ...

Fixed bug #66041: list() fails to unpack yielded ArrayAccess object

Yield return values now use IS_VAR rather than IS_TMP_VAR. This
fixes the issue with list() and should also be faster

Fixed bug #66041: list() fails to unpack yielded ArrayAccess object

Yield return values now use IS_VAR rather than IS_TMP_VAR. This
fixes the issue with list() and should also be faster as it avoids
doing a zval copy.

show more ...

Fix bug #64979: Wrong behavior of static variables in closure generators

Save a TSRMLS_FETCH() for zval_ptr_dtor in executor

This gives me about 9% improvement on Zend/bench.php for a zts build.

Make use of direct returns in some places

typos (orig)

typos (orig)