Please warn when assigning from 'return' #13238
Comments
From @jmdhThis is a bug report for perl from dom@earth.li, Forwarded from <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512799>: "Hello, I spent significant amount of time today in debug to notice stupid line 'my $var = return myfunc($arg1, $arg2);', when of course I meant 'my $var = myfunc($arg1, $arg2);'. As assigning something a return is useless, Perl could generate a This still happens with perl 5.18.1: perl -e 'sub foo {}; sub bar { $foo = return foo() }' Flags: Site configuration information for perl 5.18.1: Configured by Debian Project at Mon Aug 26 19:34:55 UTC 2013. Summary of my perl5 (revision 5 version 18 subversion 1) configuration: Locally applied patches: @INC for perl 5.18.1: Environment for perl 5.18.1: |
From @jkeenanOn Sat Sep 07 11:31:41 2013, dom wrote:
We could, but I don't think we should. This is the first time in 13
Thank you very much. |
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sat Sep 07 14:56:39 2013, jkeenan wrote:
I agree. I’m rejecting this ticket. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'rejected' |
From @wolfsageOn Sat, Sep 7, 2013 at 9:46 PM, Father Chrysostomos via RT <
Is there any reason not to be helpful if we can, provided it doesn't add I'd be willing to try to cut a patch for this. Seems there are a few possible bugs in public code due to this: http://grep.cpan.me/?q=[%24%40%25].*+%3D+return\s And even one in a dist shipped with perl5 itself: https://metacpan.org/source/RJBS/perl-5.18.0/cpan/CPAN/lib/CPAN/HTTP/Client.pm#L81 -- Matthew Horsfall (alh) |
From @cpansproutOn Mon Sep 09 11:27:26 2013, alh wrote:
Wow. I didn’t realise it was that common. If you want to write a (Just don’t warn for my $x = foo || return.) -- Father Chrysostomos |
|
@cpansprout - Status changed from 'rejected' to 'open' |
From perl@profvince.comOn 09/09/2013 20:26, Matthew Horsfall (alh) wrote:
Removing the optree tests, the comment matches and the non-perl5 code I believe the proper place for a warning that tries to catch such a rare Vincent |
From @wolfsageOn Mon, Sep 9, 2013 at 4:30 PM, Vincent Pit <perl@profvince.com> wrote:
It's valid syntax, but with "surprising" results. It seems like it should I think it'd be great if any code that couldn't be reached threw a warning, -- Matthew Horsfall (alh) |
From @ap* Matthew Horsfall (alh) <wolfsage@gmail.com> [2013-09-10 01:45]:
my $arg = shift || return;
A generic dead code detector would be really useful. A special case for -- |
From @wolfsageOn Thu, Sep 12, 2013 at 2:36 AM, Aristotle Pagaltzis <pagaltzis@gmx.de> wrote:
What are the complaints against something like this? I don't understand why we wouldn't want to help people write less buggy Perl. If there's obvious downsides to this that far outweigh the benefits, Thanks, -- Matthew Horsfall (alh) |
From @xdgOn Thu, Sep 12, 2013 at 10:56 AM, Matthew Horsfall (alh)
The longest journey begins with a single step. :-) More seriously, I think we have plenty of special case code to warn I see little harm in adding another. (Since I probably cut/paste my David -- |
From @ikegamiOn Thu, Sep 12, 2013 at 2:24 PM, David Golden <xdg@xdg.me> wrote:
It's already been taken, actually. $ perl -cwe'sub logerror {} exec("foo"); logerror(); die;'
|
From @ap* Matthew Horsfall (alh) <wolfsage@gmail.com> [2013-09-12 17:00]:
We do want to help people write less buggy Perl. We also want to help Two options for the trigger: 1. Very robust but very restricted, e.g. only for `return` immediately 2. Generic but much more complex and probably reliant on heuristics, Triage: 1. How many people is a warning for `my $foo = return 1` really going to 2. More realistically useful; also a lot more complex, with potential to I just don’t see a special-case check for this specific issue pulling Over and out, |
From @jkeenanOn Thu Sep 12 20:10:55 2013, aristotle wrote:
On the basis of Aristotle's analysis -- and on my own belief that there's only so much hand-holding we should be providing to our users -- I recommend that this feature request be rejected. Thank you very much. |
From @wolfsageOn Sat Nov 16 19:13:50 2013, jkeenan wrote:
Done. -- Matthew Horsfall (alh) |
|
@wolfsage - Status changed from 'open' to 'rejected' |
Migrated from rt.perl.org#119665 (status was 'rejected')
Searchable as RT119665$
The text was updated successfully, but these errors were encountered: