use overload fallback = 0 doesn't seem to always work

[p5pRT]

Migrated from rt.perl.org#111856 (status was 'resolved')

Searchable as RT111856$

[p5pRT]

From @khwilliamson

This is a bug report for perl from khw@​karl.(none),
generated with the help of perlbug 1.39 running under perl 5.15.8.

---

On 18 March 2012 17​:35, Karl Williamson <public@​khwilliamson.com> wrote​:

use overload
fallback = 0,
'&' = sub {...},
'=' = sub {...},
'+=' = sub{...};

There is no definition for '&='. But the statement

$a &= $b; # $a and $b are both the same object type

doesn't give a compilation error; it generates code that calls the method
for '&', does not call the copy constructor, the result being doing the
wrong thing. That cost me several hours time.

overload​::Method($obj, "&=") returns undef

fallback=0 is supposed to prevent autogeneration. Running with -Do shows
this​:

   Overloaded operator "&" \(initially "&="\)​: method for right 

argument

found

Shouldn't fallback=0 prevent this? If not, the documents need
clarification.

On 19 March 2012, Rafael Garcia-Suarez <rgs@​consttype.org> wrote​:

I ohink it's a bug (not limited to &=). This code dies with an error :

~§ cat oand.pl
use 5.010;
use overload fallback => 0, '""' => sub { $_[0]{a} }, '+' => sub { say
"overload(@​_)" ; 42 };
$x = bless { a => "x" }; $y = bless { a => "y" };
say( $x += 11 );
~§ bleadperl oand.pl
Operation "+="​: no method found,
  left argument in overloaded package main,
  right argument has no overloaded magic at oand.pl line 4.

  However, insert another form of assignment before the $x+=11
and it runs fine :

  ~§ cat oand.pl
  use 5.010;
  use overload fallback => 0, '""' => sub { $_[0]{a} }, '+' =>
sub { say
  "overload(@​_)" ; 42 };
  $x = bless { a => "x" }; $y = bless { a => "y" };
  say( $x += $y );
  say( $x += 11 );
  ~§ bleadperl oand.pl
  overload(y x 1)
  42
  53

  You'll also notice that overload, for no clear reason, swaps $x
in $y
  in the first call to the generated +=. So I suspect a logic bug
around
  the code that checks if the arguments can be swapped.

  Also, you're hitting one of the very old items in my todo list
: write
  a good test suite for overload

---

---

Flags​:
  category=core
  severity=low

---

Site configuration information for perl 5.15.8​:

Configured by khw at Mon Mar 19 08​:09​:43 MDT 2012.

Summary of my perl5 (revision 5 version 15 subversion 8) configuration​:
  Commit id​: b5bf278
  Platform​:
  osname=linux, osvers=2.6.35-32-generic-pae,
archname=i686-linux-thread-multi-64int-ld
  uname='linux karl 2.6.35-32-generic-pae #66-ubuntu smp mon feb 13
21​:21​:45 utc 2012 i686 gnulinux '
  config_args='-des -Dprefix=/home/khw/blead -Dusedevel
-D'optimize=-ggdb3' -A'optimize=-ggdb3' -A'optimize=-O0' -Dman1dir=none
-Dman3dir=none -DDEBUGGING -Dcc=g++ -Dusemorebits -Dusethreads'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=undef, uselongdouble=define
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='g++', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O0 -ggdb3',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.4.5', gccosandvers=''
  intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
  ivtype='long long', ivsize=8, nvtype='long double', nvsize=12,
Off_t='off_t', lseeksize=8
  alignbytes=4, prototype=define
  Linker and Libraries​:
  ld='g++', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib
/usr/lib/i686-linux-gnu
  libs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
  libc=/lib/../lib/libc.so.6, so=so, useshrplib=false, libperl=libperl.a
  gnulibc_version='2.12'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -ggdb3 -ggdb3 -O0
-L/usr/local/lib -fstack-protector'

Locally applied patches​:

---

@​INC for perl 5.15.8​:

/home/khw/blead/lib/perl5/site_perl/5.15.8/i686-linux-thread-multi-64int-ld
  /home/khw/blead/lib/perl5/site_perl/5.15.8
  /home/khw/blead/lib/perl5/5.15.8/i686-linux-thread-multi-64int-ld
  /home/khw/blead/lib/perl5/5.15.8
  /home/khw/blead/lib/perl5/site_perl
  .

---

Environment for perl 5.15.8​:
  HOME=/home/khw
  LANG=en_US.UTF-8
  LANGUAGE=en_US​:en
  LD_LIBRARY_PATH (unset)
  LOGDIR (unset)

PATH=/home/khw/bin​:/home/khw/print/bin​:/bin​:/usr/local/sbin​:/usr/local/bin​:/usr/sbin​:/usr/bin​:/sbin​:/usr/games​:/home/khw/cxoffice/bin
  PERL5OPT=-w
  PERL_BADLANG (unset)
  SHELL=/bin/ksh

[p5pRT]

From @rgarcia

On 20 March 2012 02​:12, karl williamson <perlbug-followup@​perl.org> wrote​:

On 18 March 2012 17​:35, Karl Williamson <public@​khwilliamson.com> wrote​:
 >
 > use overload
 >        fallback = 0,
 >        '&' = sub {...},
 >        '=' = sub {...},
 >        '+=' = sub{...};
 >
 > There is no definition for '&='.  But the statement
 >
 >  $a &= $b; # $a and $b are both the same object type
 >
 > doesn't give a compilation error; it generates code that calls the method
 > for '&', does not call the copy constructor, the result being doing the
 > wrong thing. That cost me several hours time.
 >
 > overload​::Method($obj, "&=") returns undef
 >
 > fallback=0 is supposed to prevent autogeneration.  Running with -Do shows
 > this​:
 >
 >        Overloaded operator "&" (initially "&=")​: method for right
argument
 > found
 >
 > Shouldn't fallback=0 prevent this?  If not, the documents need
 > clarification.

On 19 March 2012, Rafael Garcia-Suarez <rgs@​consttype.org> wrote​:

I ohink it's a bug (not limited to &=). This code dies with an error :

~§ cat oand.pl
use 5.010;
use overload fallback => 0, '""' => sub { $_[0]{a} }, '+' => sub { say
"overload(@​_)" ; 42 };
$x = bless { a => "x" }; $y = bless { a => "y" };
say( $x += 11 );
~§ bleadperl oand.pl
Operation "+="​: no method found,
    left argument in overloaded package main,
        right argument has no overloaded magic at oand.pl line 4.

        However, insert another form of assignment before the $x+=11
and it runs fine :

        ~§ cat oand.pl
        use 5.010;
        use overload fallback => 0, '""' => sub { $_[0]{a} }, '+' =>
sub { say
        "overload(@​_)" ; 42 };
        $x = bless { a => "x" }; $y = bless { a => "y" };
        say( $x += $y );
        say( $x += 11 );
        ~§ bleadperl oand.pl
        overload(y x 1)
        42
        53

        You'll also notice that overload, for no clear reason, swaps $x
in $y
        in the first call to the generated +=. So I suspect a logic bug
around
        the code that checks if the arguments can be swapped.

        Also, you're hitting one of the very old items in my todo list
: write
        a good test suite for overload

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Here's the commit message. The patch itself is fairly simple.

commit 809f751e6a79849f8fa71568def987da0addbe27
Author​: Rafael Garcia-Suarez <rgs@​consttype.org>
Date​: Tue Mar 20 09​:17​:02 2012 +0100

  Lookup overloaded assignment operators when trying to swap the arguments

  This is in the case where we search for an overloaded operator when
  passing the AMGf_assign flag (we're executing an assignment operator
  like +=).

  At the very beginning of Perl_amagic_call, if the flag AMGf_noleft is
  not passed, we first try to look up the overload method corresponding
  to the assignment operator, then the normal one if fallback is
  authorized. However, if this fails, when trying later to find
  overload magic with the arguments swapped (if AMGf_noright is not
  passed), this procedure was not used and we looked up directly the base
  operation from which the assignment operator might be derived.
  As a consequence of what an operator like += might have looked
  autogenerated even when fallback=>0 was passed.

  This change only necessitates a minor adjustment in lib/overload.t,
  where an overloaded += method wasn't corresponding semantically to the
  overloaded + method of the same class, which can be seen as a
  pathological case.

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @rjbs

* Rafael Garcia-Suarez <rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

--
rjbs

[p5pRT]

From @khwilliamson

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez <rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?
--
Karl Williamson

[p5pRT]

From @rgarcia

On 9 April 2012 07​:00, Karl Williamson via RT <perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez <rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch.  mktables (which
had the original problem) fails to compile because of a missing
overloaded op.  When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong.  That appears to be the
only file in error.  It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

[p5pRT]

From @khwilliamson

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via RT<perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

[p5pRT]

From @khwilliamson

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug. So, once 5.17 opens, I'll submit
fixes for my portion first, then your patch.

[p5pRT]

From @rgarcia

On 11 April 2012 06​:06, Karl Williamson <public@​khwilliamson.com> wrote​:

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug.  So, once 5.17 opens, I'll submit fixes
for my portion first, then your patch.

I've committed a small fix to mktables in my branch rgs/overload after
having it rebased on top of blead :

http​://perl5.git.perl.org/perl.git/log/refs/heads/rgs/overload

If it looks good I'm inclined to merge this branch in blead.

[p5pRT]

From @khwilliamson

On 05/22/2012 09​:34 AM, Rafael Garcia-Suarez via RT wrote​:

On 11 April 2012 06​:06, Karl Williamson<public@​khwilliamson.com> wrote​:

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug. So, once 5.17 opens, I'll submit fixes
for my portion first, then your patch.

I've committed a small fix to mktables in my branch rgs/overload after
having it rebased on top of blead :

http​://perl5.git.perl.org/perl.git/log/refs/heads/rgs/overload

If it looks good I'm inclined to merge this branch in blead.

I have a local topic branch that includes your overload patch, among
others, including things to update mktables to work with it. I haven't
read your mktables patch, perhaps they are the same.

I was planning to deliver the topic branch in the next couple weeks. I
have no real objection to your committing earlier what you have, but it
could make rebasing a little harder for me, so I suggest holding off.

[p5pRT]

From @rgarcia

On 23 May 2012 05​:49, Karl Williamson <public@​khwilliamson.com> wrote​:

On 05/22/2012 09​:34 AM, Rafael Garcia-Suarez via RT wrote​:

On 11 April 2012 06​:06, Karl Williamson<public@​khwilliamson.com>  wrote​:

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org>  wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org>  [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think
that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug.  So, once 5.17 opens, I'll submit
fixes
for my portion first, then your patch.

I've committed a small fix to mktables in my branch rgs/overload after
having it rebased on top of blead :

http​://perl5.git.perl.org/perl.git/log/refs/heads/rgs/overload

If it looks good I'm inclined to merge this branch in blead.

I have a local topic branch that includes your overload patch, among others,
including things to update mktables to work with it.  I haven't read your
mktables patch, perhaps they are the same.

I was planning to deliver the topic branch in the next couple weeks.  I have
no real objection to your committing earlier what you have, but it could
make rebasing a little harder for me, so I suggest holding off.

The mktable patch is just a 2-line patch to separate stringification
and concatenation (because .= is no longer generated). I wanted to
merge my branch to shake out overload breakages in CPAN modules, but I
suppose I can already start building half of CPAN (tm) with blead + my
patch.

[p5pRT]

From @khwilliamson

On 05/23/2012 01​:05 AM, Rafael Garcia-Suarez wrote​:

On 23 May 2012 05​:49, Karl Williamson<public@​khwilliamson.com> wrote​:

On 05/22/2012 09​:34 AM, Rafael Garcia-Suarez via RT wrote​:

On 11 April 2012 06​:06, Karl Williamson<public@​khwilliamson.com> wrote​:

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org> wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org> [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think
that
more tests are needed in general from overload. (I guess it will be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables (which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something else
that could be going wrong?

Given that my patch only changes some code inside an if() condition, I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug. So, once 5.17 opens, I'll submit
fixes
for my portion first, then your patch.

I've committed a small fix to mktables in my branch rgs/overload after
having it rebased on top of blead :

http​://perl5.git.perl.org/perl.git/log/refs/heads/rgs/overload

If it looks good I'm inclined to merge this branch in blead.

I have a local topic branch that includes your overload patch, among others,
including things to update mktables to work with it. I haven't read your
mktables patch, perhaps they are the same.

I was planning to deliver the topic branch in the next couple weeks. I have
no real objection to your committing earlier what you have, but it could
make rebasing a little harder for me, so I suggest holding off.

The mktable patch is just a 2-line patch to separate stringification
and concatenation (because .= is no longer generated). I wanted to
merge my branch to shake out overload breakages in CPAN modules, but I
suppose I can already start building half of CPAN (tm) with blead + my
patch.

On further thought, your patch doesn't logically belong in my topic
branch, so I think you should just commit them (it plus what is needed
in mktables to get it to work) at your convenience.

[p5pRT]

From @rgarcia

On 23 May 2012 15​:28, Karl Williamson <public@​khwilliamson.com> wrote​:

On 05/23/2012 01​:05 AM, Rafael Garcia-Suarez wrote​:

On 23 May 2012 05​:49, Karl Williamson<public@​khwilliamson.com>  wrote​:

On 05/22/2012 09​:34 AM, Rafael Garcia-Suarez via RT wrote​:

On 11 April 2012 06​:06, Karl Williamson<public@​khwilliamson.com>
 wrote​:

On 04/10/2012 09​:31 AM, Karl Williamson wrote​:

On 04/10/2012 08​:55 AM, Rafael Garcia-Suarez via RT wrote​:

On 9 April 2012 07​:00, Karl Williamson via
RT<perlbug-followup@​perl.org>    wrote​:

On Thu Mar 22 14​:49​:33 2012, perl.p5p@​rjbs.manxome.org wrote​:

* Rafael Garcia-Suarez<rgs@​consttype.org>    [2012-03-20T05​:59​:56]

I pushed a fix for this to branch rgs/overload. I strongly think
that
more tests are needed in general from overload. (I guess it will
be
for 5.17)

Thanks, I've added this to early-5.17-stuff.

I have tried testing this by switching to this branch. mktables
(which
had the original problem) fails to compile because of a missing
overloaded op. When I comment out the single heredoc that caused
this
problem, mktables appears to work fine, but the result file,
lib/unicore/lib/Gc/Cs.pl, is now very wrong. That appears to be the
only file in error. It is supposed to be one range, the surrogates.

I suppose what could be going on is that an op that previously was
auto-generated is now not, but now there is a base class op that
gets
used instead. and that op is wrong.

Does this seem like a possibility, or can you think of something
else
that could be going wrong?

Given that my patch only changes some code inside an if() condition,
I
would tend to think you did not build from a completely clean source
tree ?

It's completely reproducible on a clean blead. I have found the
particular Perl line that causes the problem, and will use the
debugger
to single step through the overload calls sequence to see where things
go awry. Results to follow

It turns out it is entirely my bug.  So, once 5.17 opens, I'll submit
fixes
for my portion first, then your patch.

I've committed a small fix to mktables in my branch rgs/overload after
having it rebased on top of blead :

http​://perl5.git.perl.org/perl.git/log/refs/heads/rgs/overload

If it looks good I'm inclined to merge this branch in blead.

I have a local topic branch that includes your overload patch, among
others,
including things to update mktables to work with it.  I haven't read your
mktables patch, perhaps they are the same.

I was planning to deliver the topic branch in the next couple weeks.  I
have
no real objection to your committing earlier what you have, but it could
make rebasing a little harder for me, so I suggest holding off.

The mktable patch is just a 2-line patch to separate stringification
and concatenation (because .= is no longer generated). I wanted to
merge my branch to shake out overload breakages in CPAN modules, but I
suppose I can already start building half of CPAN (tm) with blead + my
patch.

On further thought, your patch doesn't logically belong in my topic branch,
so I think you should just commit them (it plus what is needed in mktables
to get it to work) at your convenience.

OK. I just merged it in blead (after running the tests), now let the
CPAN breakage begin :)

[p5pRT]

@rgs - Status changed from 'open' to 'resolved'

[p5pRT]

From @cpansprout

On Wed May 23 07​:41​:07 2012, rgs@​consttype.org wrote​:

OK. I just merged it in blead (after running the tests), now let the
CPAN breakage begin :)

In general, could you try to rebase before merging? It would make the
shortlog at http​://perl5.git.perl.org/perl.git less confusing. :-)

--

Father Chrysostomos