From ce3819cf202a3c5c172fdfaee0412bb5576cf2c7 Mon Sep 17 00:00:00 2001 From: Yves Orton Date: Tue, 29 Nov 2022 12:00:31 +0100 Subject: 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. --- perl.c | 5 ----- 1 file changed, 5 deletions(-) (limited to 'perl.c') 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 -- cgit v1.2.1