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
Bleadperl v5.27.5-398-g19a8de4862 breaks MLEHMANN/AnyEvent-HTTP-2.23.tar.gz #16284
Comments
From @andkThanks to Slaven for discovering this one. bisect points to: : commit 19a8de4 This is the second BBC for this distro in a short row. The other is To produce the new one I applied Ilmari's patch for AnyEvent-7.14. Diagnostics now: : Can't modify delete in substr at /tmp/loop_over_bdir-15721-ERyp63/AnyEvent-HTTP-2.23-0/blib/lib/AnyEvent/HTTP.pm line 1104, near """)" perl -V Summary of my perl5 (revision 5 version 27 subversion 6) configuration: Characteristics of this binary (from libperl): -- |
From @cpansproutOn Fri, 01 Dec 2017 15:27:39 -0800, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
I have a fix for that first error. I will push it as soon as tests finish.
I hope these are just side-effects of the first error. -- Father Chrysostomos |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Fri, 01 Dec 2017 18:21:29 -0800, sprout wrote:
Now pushed as 833d07d.
Do you still get these other errors? -- Father Chrysostomos |
From @andk
> Do you still get these other errors? Beautiful: : All tests successful. This ticket can be closed. Thanks! |
@iabyn - Status changed from 'open' to 'resolved' |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
The change you've made is to use loose lvalue context for the first arg As far as I can see, AnyEvent::HTTP has no reason to use a mutating I reckon commit 833d07d should be -zefram |
From @cpansproutOn Mon, 04 Dec 2017 09:37:56 -0800, zefram@fysh.org wrote:
The acceptance or rejection of any particular op as an lvalue is necessarily arbitrary. There is actually no syntactic need for 3=4 to be prohibited, because it will croak at run time anyway. The only reason it is prohibited is that it would be unhelpful to programmers to allow such obviously sloppy code to compile. This arbitrariness actually prevents some useful constructs: ++tie $X, "foo"; If foo::TIESCALAR returns an object with overloading that makes ++ meaningful, then that construct could be used, were it not for the compile-time check. I’m not arguing that this case should be made to work. I’m just using it as an example to demonstrate how arbitrary compile-time lvalue checks are. Other examples: ${\3} = 4; # This could die at compile time.
It may be that AnyEvent::HTTP is using four-argument substr unnecessarily. But I tend to see *any* CPAN failure as merely a canary in the coalmine, and not the only failure. The fact that AnyEvent::HTTP uses it that way is enough to prove that we have broken backward-compatibility when we did not need to. Since the first argument to substr has never ever had strict compile-time lvalue checks applied to it, I think it would be wrong to impose it now, because of the arbitrariness I mentioned above.
I think backward compatibility should win. The current (restored) behaviour is not clearly a bug. -- Father Chrysostomos |
From zefram@fysh.orgFather Chrysostomos via RT wrote:
This is true; there is some arbitrariness, and even a few cases where it's
It is just as helpful to reject substr on a delete as it is to reject -zefram |
From @cpansproutOn Mon, 04 Dec 2017 13:53:36 -0800, zefram@fysh.org wrote:
And it is also helpful to allow it. Traditionally Perl has retained backward compatibility in such cases. I do not believe we can reach an agreement on this. It would be helpful if someone else would chip in. -- Father Chrysostomos |
Migrated from rt.perl.org#132527 (status was 'resolved')
Searchable as RT132527$
The text was updated successfully, but these errors were encountered: