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
=> search too weak #10718
Comments
From zefram@fysh.orgCreated by zefram@fysh.orgThe determination of whether a "{" is the start of a block or a hash $ perl -lwe '{ foo => 1 }->${\sub{ print @_ }}' It should really be willing to add the next line to the buffer, and do a Perl Info
|
From @jkeenanOn Tue Oct 12 11:58:29 2010, zefram@fysh.org wrote:
My subjective reaction to that last line of code is: "Whoever writes
Less subjectively, I feel we should ask: Do we really need this
Thank you very much. |
The RT System itself - Status changed from 'new' to 'open' |
From @rjbsI think it's reasonable to reduce the number of places where the kind of |
From @cpansproutOn Sun Jan 22 15:28:05 2012, rjbs wrote:
This really *is* a bug. It behaves as expected inside /(?{ ... })/ or a These are both valid: /(?{ eval ' -- Father Chrysostomos |
From @cpansproutHere is another instance of this bug. OK, so => quotes a bare word: $ perl -le 'sub foo; $_ = foo => ' -e 'print $_' even if it is on the following line: $ perl -le '$_ = foo ' -e '=> print $_' Let’s try __DATA__: $ perl -le '$_ = __DATA__ =>' -e 'print $_' $ perl -le '$_ = __DATA__' -e '=> print $_' Now that happens to apply to any built-in keyword. I am trying to fix Do we want this to quote __DATA__? __DATA__ (Apologies to the authors of Devel::PPPort.) I think we *do* want it to. => needs to be generic. For a keyword to BTW: $ perl -le 'print eval "__DATA__\n\n\n=>"' But it doesn’t work with comments. -- Father Chrysostomos |
From @rjbs* Father Chrysostomos via RT <perlbug-followup@perl.org> [2013-07-12T04:19:08]
So, __DATA__ and __END__ are special tokens that tell the parser the file is use strict; __END__ * $x; # okay! the * x is never reached Or: ~$ perl -MData::Dumper -E 'say Dumper __DATA__ => 2' ~$ perl -MData::Dumper -E 'say Dumper __DATA__ ==> 2' I think the specialness of __END__ and __DATA__ should be trumping the I think this is an accurate CPAN grep: http://grep.cpan.me/?q=__%28END%7CDATA%29__%5Cs*%3D%3E The construct occurs hardly at all, and it looks like "my fix" would break one I am very uncomfortable about => quoting __DATA__. -- |
From @cpansproutOn Fri Jul 12 07:15:43 2013, perl.p5p@rjbs.manxome.org wrote:
After a night’s rest, and even before reading your message, I had If any keyword (and this bug applies to the keyword plugin, too) can -- Father Chrysostomos |
From @cpansproutOn Fri Jul 12 01:19:07 2013, sprout wrote:
I have fixed it in commit 5969c57 for all keywords *except* __DATA__ The instance of this bug in the original post has not been fixed. -- Father Chrysostomos |
From @cpansproutOn Fri Jul 12 23:11:33 2013, sprout wrote:
I have just reverted it in commit c3eee33. It doesn’t work on non-mad -- Father Chrysostomos |
From @cpansproutOn Fri Jul 12 23:25:11 2013, sprout wrote:
It is now back in as 2179133. -- Father Chrysostomos |
Migrated from rt.perl.org#78348 (status was 'open')
Searchable as RT78348$
The text was updated successfully, but these errors were encountered: