diff options
author | David Mitchell <davem@iabyn.com> | 2018-02-19 11:59:03 +0000 |
---|---|---|
committer | David Mitchell <davem@iabyn.com> | 2018-02-19 22:06:49 +0000 |
commit | 55b62dee2d8dffa7b36b3b613ee4727fbefdb9e3 (patch) | |
tree | af99f9325739767173f08bc999ba0e8bfac281b5 /l1_char_class_tab.h | |
parent | 057ba76ababce335660483d8ac1f9a460182c91c (diff) | |
download | perl-55b62dee2d8dffa7b36b3b613ee4727fbefdb9e3.tar.gz |
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
Diffstat (limited to 'l1_char_class_tab.h')
0 files changed, 0 insertions, 0 deletions