Front page | perl.perl5.porters |
Postings from July 2012
On Thu, Jul 05, 2012 at 10:46:26PM -0700, Andreas J. Koenig via RT wrote:
> f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
> 5f9f83be9cdcd54449f7f40db078fe367d780475
> We cannot bisect more!
For information:
$ git log f041cf0f9c6469c41de8b73d5f7b426710c3ff8b^! 5f9f83be9cdcd54449f7f40db078fe367d780475
commit 5f9f83be9cdcd54449f7f40db078fe367d780475
Author: Rafael Garcia-Suarez <rgs@consttype.org>
Date: Tue May 22 17:23:20 2012 +0200
Fix mktables bug due to the previous overload fix
Due to the previous patch, perl can't generate the operator for .= in
package Property anymore (because fallback is '0' in that package), so
we need to work around that; this patch implements the least intrusive
workaround possible.
commit f041cf0f9c6469c41de8b73d5f7b426710c3ff8b
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.
so effectively the two commits are the for the same change.
Nicholas Clark
Thread Previous
|
Thread Next