perl.c - move PL_restartop assert out of perl_run()

In dd66b1d793 we added an assert to perl_run() that PL_restartop should
never be true when perl_run() is called after perl_parse(). Looked at
from the point of the internals, which calls perl_parse() and perl_run()
exactly once, this made sense.

It turns out however that there is at least one XS module out there that
expects to be able to set PL_restartop and then call perl_run(). If that
works out for them then we shouldn't block it, as we aren't really
trying to say "perl_run() should never be called with PL_restartop set"
(at least this assert wasn't trying to say that really), we are trying
to assert "between the top level transition from perl_parse() to
perl_run() we shouldnt leak any PL_restartop".

One could argue the assert maybe should go at the end of perl_parse(),
but I chose to put it in Miniperl.pm and thus into perlmain.c and
miniperlmain.c as I am not certain that perl_parse() should never be
called with PL_restartop set already, and putting it in the main code
really does more closely reflect the intent of this assert anyway.

This was reported as Blead Breaks CPAN Github Issue #20557.

1 files changed, 0 insertions, 5 deletions

diff --git a/perl.c b/perl.c
index 835d77e771..b19578c828 100644
--- a/perl.c
+++ b/perl.c
@@ -2706,11 +2706,6 @@ perl_run(pTHXx)
 #ifndef MULTIPLICITY
     PERL_UNUSED_ARG(my_perl);
 #endif
-    /* perl_parse() may end up starting its own run loops, which might end
-     * up "leaking" PL_restartop from the parse phase into the run phase
-     * which then ends up confusing run_body(). This leakage shouldn't
-     * happen and if it does its a bug. */
-    assert(!PL_restartop);
 
     oldscope = PL_scopestack_ix;
 #ifdef VMS