Front page | perl.perl5.porters |
Postings from May 2015
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 <sprout@cpan.org>
> > 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