Re: likely regressions for debugging hooks x lua_resume() in 5.4

[Aurelien DARRAGON <adarragon@...>]

>     To resume a coroutine,
>     you remove the @id{*nresults} yielded values from its stack,
>     push the values to be passed as results from @id{yield},
>     and then call @Lid{lua_resume}.
> 
> Isn't that not enough?

I agree with you that after reading ldo.c source code and fixing the
calling program this does really make sense indeed (in the sense that
the doc is right). But I do think that it's easy to misuse the <narg> by
mistake when first using it, and since 5.3 kept working despite that
(call it more permissive?) it somewhat hid the issue for a long time,
and now this could result in latent bugs that may reappear much later
when migrating from 5.3 to 5.4 with no meaningful error message, and
since the doc doesn't mention this pitfall, I think that it could
confuse others, like it confused me initially. As for 5.4 newcomers,
given the unexpected behavior only arises when yielding from a debug
hook, it could as well take some time for the user to realize its
mistake if he doesn't revisit the lua_resume() call after implementing
extra debug hook logic.

Anyway, now at least there is this thread that documents this :)

> The documentation says that "The parameter @id{from} represents the
> coroutine that is resuming @id{L}." Is seems weird (and invalid) for a
> coroutine to resume itself. The documentation also says that
> "If there is no such coroutine, this parameter can be @id{NULL}."

Understood, now I'm convinced.
And now that I realize, sorry for the eye-catching email title, since
both "regressions" actually resulted from improper use of the
lua_resume() function, so it's not right to call them regressions anymore.

Thanks,
Aurelien