py/objgenerator.c: Allow pend_throw to an unstarted generator.

[jimmo]

pend_throw is a MicroPython-specific extension but allows simplification of the implementation of uasyncio. It injects an exception into the generator such that it will be raised as soon as it is next resumed.

This fixes the behaviour specifically such that uasyncio.cancel() will work on an unstarted generator. See #5242

[kevinkk525]

I just tested the behaviour and can confirm that it works as expected. Thanks.

[jimmo]

Updated tests to catch the missing coverage.

[dpgeorge]

Overall code-size change for this PR is:

   bare-arm:   -24 -0.036% 
minimal x86:   -12 -0.008% 
   unix x64:   -48 -0.010% 
unix nanbox:    -8 -0.002% 
      stm32:   -20 -0.006% PYBV10
     cc3200:   -32 -0.017% 
    esp8266:   -44 -0.007% GENERIC
      esp32:   -32 -0.003% GENERIC[incl -32(data)]
        nrf:   +24 +0.016% pca10040
       samd:   -32 -0.031% ADAFRUIT_ITSYBITSY_M4_EXPRESS

So, independently of whether this is eventually useful for uasyncio, I'd say it's a good change because 1) it generalises a feature; 2) it reduces code size.

[dpgeorge]

now needs to be replaced with raised ValueError()

[jimmo]

Done

[kevinkk525]

A quick question to your PR:
I saw an attribute "pend_exc" that was "is_running" before but the purpose is not entirely clear to me: Does it indicate the generators general status? Like will it be running until it is fully cancelled or does it only indicate that the generator is currently executing some code until it yields?

If it indicates the general status of a generator, could it be used to implement the CPython equivalent of "task.done()" returning if the generator is finished executing code?
This way we would be able to check if a generator is fully canceled/finished without having a task implementation.
If that is not the case and the attribute is used differently, you don't need to explain it, my understanding is not important in this case :D I just thought about "coro.done()" when I saw it.

[jimmo]

I saw an attribute "pend_exc" that was "is_running" before but the purpose is not entirely clear to me: Does it indicate the generators general status? Like will it be running until it is fully cancelled or does it only indicate that the generator is currently executing some code until it yields?

It's the latter. i.e. the generator is currently executing code up to the next yield. This really only exists to prevent trying to call next/send/throw (or pend_throw) on itself. (See the test case I added that shows this in action).

If it indicates the general status of a generator, could it be used to implement the CPython equivalent of "task.done()" returning if the generator is finished executing code?
This way we would be able to check if a generator is fully canceled/finished without having a task implementation.

Yeah, unfortunately it doesn't, but it could actually be easily extended to do so with another sentinel value (this is actually what I had in my mind when I wrote "another extension to objgenerator.c to interrogate a generator instance and find out whether it has finished" on #5242

[dpgeorge]

Why is this restriction needed? Can this check just be removed? If the user passes in None then it just cancels any pending throw, which seems sensible/possible...?

[jimmo]

Yes, you're right. Removed and updated the test to check that this works.

I think this was left over from when I had the meaning of MP_OBJ_NULL and mp_const_none the other way around.

[dpgeorge]

With the latest changes/fixes to this PR the code-size change is:

   bare-arm:   -48 -0.072% 
minimal x86:   -60 -0.040% 
   unix x64:   -80 -0.016% 
unix nanbox:   -40 -0.009% 
      stm32:   -36 -0.010% PYBV10
     cc3200:   -40 -0.022% 
    esp8266:   -60 -0.009% GENERIC
      esp32:   -64 -0.005% GENERIC[incl -48(data)]
        nrf:   -36 -0.025% pca10040
       samd:   -48 -0.047% ADAFRUIT_ITSYBITSY_M4_EXPRESS

[dpgeorge]

Merged in 576ed89 and 5578182