develooper Front page | perl.perl5.porters | Postings from June 2018

[perl #132385] BBC: Commit e839e6ed breaks Bit-Vector-7.4

Thread Next
From:
slaven@rezic.de via RT
Date:
June 2, 2018 14:34
Subject:
[perl #132385] BBC: Commit e839e6ed breaks Bit-Vector-7.4
Message ID:
rt-4.0.24-24137-1527950085-760.132385-15-0@perl.org
Dana Tue, 20 Feb 2018 01:25:16 -0800, davem reče:
> On Fri, Feb 09, 2018 at 07:46:59PM +0000, Dave Mitchell wrote:
> > On Mon, Feb 05, 2018 at 11:33:08PM +0000, Zefram wrote:
> > > Bisects to commit e839e6ed99c6b25aee589f56bb58de2f8fa00f41 "Add
> > > OP_MULTICONCAT op".
> > 
> > Reduces to:
> > 
> >         use overload
> >             '""' => sub { print qq{"" called\n}; "B" },
> >             "."  => sub { print qq{.  called\n}; bless [] },
> >         ;
> > 
> >         my $a   = "A";
> >         my $obj = bless [];
> >         my $s;
> >         $s = "$a-$obj";
> > 
> >     $ perl5260 ~/tmp/p; echo ===; perl5278 ~/tmp/p
> >     .  called
> >     "" called
> >     ===
> >     .  called
> >     $
> > 
> > I've added it to my Big List of Overloaded Concat Things That Multiconcat
> > Broke, which I'm currently working on.
> 
> 
> Now fixed with the following commit. Note that it merely restores the
> existing buggy and inconsistent 5.26.0 and earlier behaviour. I'll
> look into whether to rationalise such behaviour post 5.28.0 release.
> 
> commit 55b62dee2d8dffa7b36b3b613ee4727fbefdb9e3
> Author:     David Mitchell <davem@iabyn.com>
> AuthorDate: Mon Feb 19 11:59:03 2018 +0000
> Commit:     David Mitchell <davem@iabyn.com>
> CommitDate: Mon Feb 19 22:06:49 2018 +0000
> 
>     pp_multiconcat: correctly honour stringify
>     
>     RT #132793, RT #132801
>     
>     In something like $x .= "$overloaded", the $overloaded stringify method
>     wasn't being called.
>     
>     However, it turns that the existing (pre-multiconcat) behaviour is also
>     buggy and inconsistent. That behaviour has been restored as-is.
>     At some future time, these bugs might be addressed.
>     
>     Here are some comments from the new tests added to overload.t:
>     
>     Since 5.000, any OP_STRINGIFY immediately following an OP_CONCAT
>     is optimised away, on the assumption that since concat will always
>     return a valid string anyway, it doesn't need stringifying.
>     So in "$x", the stringify is needed, but on "$x$y" it isn't.
>     This assumption is flawed once overloading has been introduced, since
>     concat might return an overloaded object which still needs stringifying.
>     However, this flawed behaviour is apparently needed by at least one
>     module, and is tested for in opbasic/concat.t: see RT #124160.
>     
>     There is also a wart with the OPpTARGET_MY optimisation: specifically,
>     in $lex = "...", if $lex is a lexical var, then a chain of 2 or more
>     concats *doesn't* optimise away OP_STRINGIFY:
>     
>     $lex = "$x";        # stringifies
>     $lex = "$x$y";      # doesn't stringify
>     $lex = "$x$y$z..."; # stringifies
> 

This issue was closed, but not all affected CPAN modules got a ticket. I created one for Lexical-Types:
https://rt.cpan.org/Ticket/Display.html?id=125465
But maybe others have to be checked.


---
via perlbug:  queue: perl5 status: resolved
https://rt.perl.org/Ticket/Display.html?id=132385

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About