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.
This fixes bugs #65035 and #65161. In one of the bugs the issue is
that function_state.arguments is NULL, but the arg count is pushed
to the stack and the code tries to free it. In the other bug the
stack of the generator is freed twice, once in generator_close and
later during shutdown.
It's rather hard (if at all possible) to do a proper stack cleanup
on an unclean shutdown, so I'm just disabling it in this case.
This also reverses the destruction order of the pushed arguments to
align with how it is done everywhere else.
I'm not exactly sure whether this is the right way to fix it, but it
seems to work fine.
Rule of thumb: Always implement the object clone handler rather
than the object storage clone handler. Actually I think we should
drop the latter. It's nearly never usable.
If a generator is destroyed in a finally block it will resume the generator to run that finally
block before freeing the generator. This was done in the object storage free handler.
Running user code in the free handler isn't safe though because the free handlers may be run
during request shutdown, already after several key components have been shut down.
This is avoided by doing the finally handling in the dtor handler. These handlers are run at the
start of the shutdown sequence.
Generator::throw($exception) throws an exception into the generator. The
exception is thrown at the current point of suspension within the generator.
It basically behaves as if the current yield statement were replaced with
a throw statement and the generator subsequently resumed.
If zend_generator_close is called from within zend_generator_resume (e.g.
due to a return statement) then all the EGs will still be using the values
from the generator. That's why the stack frame has to be the last thing
that is dtored, otherwise some other dtor that is using
EG(current_execute_data) might access the already freed memory segment.
This was the case with the closure dtor.
The fix is to move the dtors for key and value to the start of the handler.
This way the stack frame is the last thing that is freed.
When the return value of yield wasn't used it was leaked.
This is fixed by using a TMP_VAR return value instead of VAR. TMP_VARs are
automatically freed when they aren't used.
EG(arg_types_stack) is now also backed up when generators are used. This
allows the use of yield in nested method calls.
This commit adds two new functions to the zend_ptr_stack API:
zend_ptr_stack_push_from_memory
zend_ptr_stack_pop_into_memory
both taking the following arguments:
zend_ptr_stack *stack, int count, void **pointers
If you try to traverse an already closed generator an exception will now be
thrown.
Furthermore this changes the error for traversing a by-val generator by-ref
from an E_ERROR to an Exception.
* Trying to resume a generator while it is already running now throws a
fatal error.
* Trying to use yield in finally while the generator is being force-closed
(by GC) throws a fatal error.
* Rewinding after the first yield now throws an Exception
It looks like you have to implement the Iterator interface *before*
assigning get_iterator. Otherwise the structure for user iterators isn't
correctly zeroed out.
Additionaly I'm setting class_entry->iterator_funcs.funcs now. Not sure if
this is strictly necessary, but better safe than sorry ;)
Previously only an error was thrown when return occured after yield. Also
returns before the first yield would fail for by-ref generators.
Now the error message is handled in pass_two, so all returns are checked.
If a generator threw an exception and was iterated using foreach (i.e. not
manually) an infinite loop was triggered. The reason was that the exception
was not properly rethrown using zend_throw_exception_internal.
foreach only allowed variables to be traversed by reference. This never
really made sense because
a) Expressions like array(&$a, &$b) can be meaningfully iterated by-ref
b) Function calls can return by-ref (so they can also be meaningfully
iterated)
c) Iterators could at least in theory also be iterated by-ref (not
sure if any iterator makes use of this)
With by-ref generators the restriction makes even less sense, so I removed
it altogether.
If yield is used in an expression context parenthesis are now required.
This ensures that the code is unambiguos.
Yield statements can still be used without parenthesis (which should be
the most common case).
Also yield expressions without value can be used without parenthesis,
too (this should be the most common case for coroutines).
If the yield expression is used in a context where parenthesis are required
anyway, no additional parenthesis have to be inserted.
Examples:
// Statements don't need parenthesis
yield $foo;
yield $foo => $bar;
// Yield without value doesn't need parenthesis either
$data = yield;
// Parentheses don't have to be duplicated
foo(yield $bar);
if (yield $bar) { ... }
// But we have to use parentheses here
$foo = (yield $bar);
This commit also fixes an issue with by-ref passing of $foo[0] like
variables. They previously weren't properly fetched for write.
Additionally this fixes valgrind warnings which were caused by access to
uninitialized memory in zend_is_function_or_method_call().
Generators are now automatically detected by the presence of a `yield`
expression in their body.
This removes the ZEND_SUSPEND_AND_RETURN_GENERATOR opcode. Instead
additional checks for ZEND_ACC_GENERATOR are added to the fcall_common
helper and zend_call_function.
This also adds a new function zend_generator_create_zval, which handles
the actual creation of the generator zval from an op array.
I feel like I should deglobalize the zend_create_execute_data_from_op_array
code a bit. It currently changes EG(current_execute_data) and
EG(opline_ptr) which is somewhat confusing (given the name).
To make the generator function show up in backtraces one has to insert an
additional execute_data into the chain, as prev_execute_data->function_state
is used to determine the called function.
Adding the additional stack frame is also required for func_get_args(), as
the arguments are fetched from there too. The arguments have to be copied
in order to keep them around. Due to the way they are saved doing so is
quite ugly, so I added another function zend_copy_arguments to zend_execute.c
which handles this.
The current situation is still not perfect, as the generator function itself
does not appear in the stack trace. This makes sense in some way, but it
would probably be more helpful if it would show up (with the bound arguments)
after the $generator->xyz() call. This could be misleading too though as the
function is not *really* called there.
Generators can now be cloned. I'm pretty sure that my current code does not
yet cover all the edge cases of cloning the execution context, so there are
probably a few bugs in there :)
During function calls arguments are pushed onto the stack. Now these are
backed up on yield and restored on resume. This requires memcpy'ing them,
but there doesn't seem to be any better way to do it.
Also this fixes the issue with exceptions thrown during function calls.
The missing piece is how one can find the next stack frame, which is
required for dtor'ing arguments pushed to the stack. As the generator
execute_data does not live on the stack one can't use it to figure out the
start of the next stack frame. So there must be some other method.
When no key is explicitely yielded PHP will used auto-incrementing keys
as a fallback. They behave the same as with arrays, i.e. the key is the
successor of the largest previously used integer key.
Keys are yielded using the
yield $key => $value
syntax. Currently this is implemented as a statement only and not as an
expression, because conflicts arise considering nesting and use in arrays:
yield yield $a => $b;
// could be either
yield (yield $a) => $b;
// or
yield (yield $a => $b);
Once I find some way to resolve these conflicts this should be available
as an expression too.
Also the key yielding code is rather copy-and-past-y for the value yielding
code, so that should be factored out.
