develooper Front page | perl.perl5.porters | Postings from May 2015

Re: ex-nextstate on commented line

Thread Previous | Thread Next
Dave Mitchell
May 11, 2015 14:05
Re: ex-nextstate on commented line
Message ID:
On Sat, May 09, 2015 at 01:52:25AM +0200, Paul Johnson wrote:
> > Bisect says it came in here:
> > 
> >   34b54951568575920f2307bea918f5549bd5a82f is the first bad commit
> >   commit 34b54951568575920f2307bea918f5549bd5a82f
> >   Author: Father Chrysostomos <>
> >   Date:   Thu Nov 20 09:23:35 2014 -0800
> > 
> >     [perl #77452] Deparse { ...; BEGIN{} } correctly
> > 
> >     8635e3c2 (5.21.6) changed the COP sequence numbers for nested blocks,
> >     such that most BEGIN blocks (incl. ‘use’ statements) and sub declara-
> >     tions end up in the right place.  However, it had the side effect of
> >     causing declarations at the end of the enclosing scope to fall out of
> >     it and appear below.
> > 
> >     This commit fixes that by adding an extra nulled COP to the end of the
> >     enclosing scope if that scope ends with a sub, so the final declara-
> >     tion gets deparsed before it.
> > 
> >     The frequency of sub declarations at the end of the enclosing scope is
> >     sufficiently low (I’m guessing a bit here) that this slight increase
> >     in run-time memory usage is probably acceptable.
> > 
> >     I had to change B::Deparse to deparse nulled COPs the same way it does
> >     live COPs, which means we get more extraneous semicolons than before.
> >     I hope to fix that in a forthcoming commit.  I also ran into a B bug,
> >     in that null ops are not presented to Perl code with the right op
> >     class (see the blessing in the patch).  I plan to fix that in a separ-
> >     ate commit, too.
> Father C doesn't seem to be around at the moment, so I wonder whether
> anyone else has any ideas on whether or not this change is acceptable?
> As far as I can tell it doesn't introduce any user visible changes, if
> we think of B::Deparse as user visible and B::Concise as not.  But it
> appears that we now have a workaround for a workaround.  And if we keep
> this I am going to need to put another layer of workaround into
> Devel::Cover.  I'll do that if necessary, but I'd be very happy if it
> were not necessary.
> So please provide your informed opinion in the space below which, unlike
> Fermat's margin, will grow to accommodate your musings.

Well, adding a non-executed ex-nextstate at the end of each block that
ends with a sub definition or use doesn't seem particularly outrageous.

This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About