New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected parsing behavior depending on number of parts in string concatination #15594
Comments
From sullr@cpan.orgCreated by sullr@cpan.orgThe following statement gets successfully parsed and executed by perl. 1 my $x = 1; > 0 at x.pl line 3. If the code is modified so that the first concationation is skipped 1 my $x = 1; > Can't modify concatenation (.) or string in scalar assignment at x.pl line 4, near "0;" The same behavior can be seen with assignments, i.e. my $z = "foobar $y " . "foo " . $x = 0; # works, $z is 0 It also works if the variable is outside the quotes or even if no quotes my $z = $x = 0; # works as expected This behavior exists in a wide range of perl versions. I found it in perl Perl Info
|
From @iabynOn Thu, Sep 08, 2016 at 12:24:52PM -0700, sullr@cpan.org wrote:
It can be reduced to the following difference: (($x . "a") . "b") = 0; # compiles (bug) -- |
The RT System itself - Status changed from 'new' to 'open' |
From zefram@fysh.orgDave Mitchell wrote:
Where a concat op has a lhs that is another concat op, ck_concat sets -zefram |
From @cpansproutOn Fri Sep 09 03:47:58 2016, zefram@fysh.org wrote:
$a.$b.$c is optimised to ($a.$b).=$c to avoid having to copy the value returned by $a.$b to a new temporary scalar to be returned by $c.
It seems that the ($a.$b).=$c optimisation can interfere in some cases with the removal of the stringify op in "$a$b$c" in some circumstances involving lexical scalar assignment. I don’t understand why though. That checking of the flag in the peephole optimizer is not directly related to this bug.
All the assignment versions of binary ops, .= += -= etc., have the OPf_STACKED flag set. -- Father Chrysostomos |
Migrated from rt.perl.org#129233 (status was 'open')
Searchable as RT129233$
The text was updated successfully, but these errors were encountered: