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
no warnings "bareword" turns off too many warnings. #1995
Comments
From abigail@arenanetworks.comCreated by abigail@arena-i.com $ perl -wle 'foo.bar' The latter should warn about the void use of concatenation. $ perl -wle 'use warnings "all"; no warnings "bareword"; foo.bar' And this should have warned only about the void use of concatenation. Abigail Perl Info
|
From [Unknown Contact. See original ticket]Created by abigail@arena-i.com $ perl -wle 'foo.bar' The latter should warn about the void use of concatenation. $ perl -wle 'use warnings "all"; no warnings "bareword"; foo.bar' And this should have warned only about the void use of concatenation. Abigail Perl Info
|
From @schwern
It seems that 'no warnings "foo"' without a preceding "use warnings"
No, "Unquoted string..." is a "reserved" warning. |
From rick@bort.caOn Tue, Jul 12, 2005 at 08:54:18PM -0700, Michael G Schwern via RT wrote:
This patch breaks test 37 of ext/B/t/deparse.t because this warning: # [Using a hash as a reference is deprecated at lib/B/Deparse.pm line 3151. is no longer suppressed by C<no warnings 'uninitialized'>. -- Inline Patchdiff -ruN perl-current/mg.c perl-current-dev/mg.c
--- perl-current/mg.c 2005-07-07 11:16:35.000000000 -0400
+++ perl-current-dev/mg.c 2005-07-13 03:37:46.973571403 -0400
@@ -781,11 +781,16 @@
if (*(mg->mg_ptr+1) == '\0')
sv_setiv(sv, (IV)((PL_dowarn & G_WARN_ON) ? TRUE : FALSE));
else if (strEQ(mg->mg_ptr+1, "ARNING_BITS")) {
- if (PL_compiling.cop_warnings == pWARN_NONE ||
- PL_compiling.cop_warnings == pWARN_STD)
- {
+ if (PL_compiling.cop_warnings == pWARN_NONE) {
sv_setpvn(sv, WARN_NONEstring, WARNsize) ;
- }
+ }
+ else if (PL_compiling.cop_warnings == pWARN_STD) {
+ sv_setpvn(
+ sv,
+ (PL_dowarn & G_WARN_ON) ? WARN_ALLstring : WARN_NONEstring,
+ WARNsize
+ );
+ }
else if (PL_compiling.cop_warnings == pWARN_ALL) {
/* Get the bit mask for $warnings::Bits{all}, because
* it could have been extended by warnings::register */
diff -ruN perl-current/t/lib/warnings/2use perl-current-dev/t/lib/warnings/2use
--- perl-current/t/lib/warnings/2use 2004-04-23 17:05:07.000000000 -0400
+++ perl-current-dev/t/lib/warnings/2use 2005-07-13 03:27:32.832203077 -0400
@@ -72,6 +72,12 @@
EXPECT
Reversed += operator at - line 3.
########
+-w
+no warnings 'reserved' ;
+foo.bar;
+EXPECT
+Useless use of concatenation (.) or string in void context at - line 3.
+########
--FILE-- abc
my $a =+ 1 ; |
From @schwernOn Wed, Jul 13, 2005 at 03:48:26AM -0400, Rick Delaney wrote:
I think this patch does the same thing without the deprecated syntax. $ perl -wle '%hash = (foo => 42); print %{"hash"}->{foo}; print ${"hash"}{foo}' I wonder what other accidentally supressed warnings this is going to --- ext/B/B/Deparse.pm 2005/07/13 22:50:34 1.1 -- |
From rick@bort.caOn Wed, Jul 13, 2005 at 03:57:39PM -0700, Michael G Schwern wrote:
Thanks, that saves me doing it.
Not too many from `make test`. Just these: t/op/inc.................................. Patch after .sig. -- Inline Patchdiff -ruN perl-current/t/op/inc.t perl-current-dev/t/op/inc.t
--- perl-current/t/op/inc.t 2005-07-09 12:13:42.000000000 -0400
+++ perl-current-dev/t/op/inc.t 2005-07-13 20:17:39.315185314 -0400
@@ -160,7 +160,7 @@
{
no warnings 'uninitialized';
- my $x, $y;
+ my ($x, $y);
eval {
$y ="$x\n";
++$x;
@@ -168,7 +168,7 @@
ok($x == 1, $x);
ok($@ eq '', $@);
- my $p, $q;
+ my ($p, $q);
eval {
$q ="$p\n";
--$p; |
From @steve-m-hayMichael G Schwern wrote:
Thanks. Applied as part of change 25153. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. |
From @steve-m-hayRick Delaney wrote:
Thanks. Applied as part of change 25153. Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. |
From p5p@spam.wizbit.beThere is still an issue with the patch that I would like to address, mixing -w, $^W and 'no warnings' results in unexpected (or atleast unexpected to me) behaviour... Example: #!perl -w $^W = 0; This results in a warning: Use of uninitialized value $b in scalar chop... Without the 'no warnings' it (obviously) doesn't warn. Ofcourse noone would do this intentionally but it might occur when old code gets mixed with new code...
It doesn't really break it but it does produce a warning on test 9 of t/io/binmode.t: Name "main::B" used only once: possible typo at t/io/binmode.t line 40. Patch: Inline Patch--- old/t/io/binmode.t 2005-07-30 22:56:59.000000000 +0200
+++ new/t/io/binmode.t 2005-07-30 22:59:31.000000000 +0200
@@ -35,7 +35,7 @@
skip "minitest", 1 if $ENV{PERL_CORE_MINITEST};
skip "no EBADF", 1 if (!exists &Errno::EBADF);
- no warnings 'io';
+ no warnings 'io', 'once';
$! = 0;
binmode(B);
ok($! == &Errno::EBADF); |
From rick@bort.caDoes this patch look ok? On Wed, Jul 13, 2005 at 03:48:26AM -0400, Rick Delaney wrote:
-- |
From guest@guest.guest.xxxxxxxxPing.
$self->talking_to("Why, yes it does!"); It would be nice if this could make it into 5.8.8. --rick
|
From @rgsGuest via RT wrote:
I applied it as change #25619 to bleadperl. For some reason it -- |
@rgs - Status changed from 'open' to 'resolved' |
From p5p@spam.wizbit.be
The patch might be ok but something is still broken... Below you find two examples: one in which a warning should be produced and another one where no warning should be produced. It does the exact opposite of what I expect... even though ${^WARNING_BITS} seems to be correct... (So I'm not sure if this is an issue with this patch or with something else) Example 1: #!perl $^W = 1; No -w, but $^W is 1 so it should produce the warning. (It produces one if 'no warnings' is left out.) Example 2: #!perl -w $^W = 0; -w is set but $^W is 0 so warnings are disabled. So the warning shouldn't be shown... My best guess is that those problems happen because the no warnings is done at compile time while $^W is changed at run time... Another thing that might not work 100% is -W and/or -X... my basic testing shows that they work as expected but I only did some basic tests... (I tried modifying the patch but without success.) Can you be kind enough to take (another) look at it? :) |
From rick@bort.caOn Tue, Nov 29, 2005 at 03:01:43PM -0800, Animator via RT wrote:
Right, so if you put the assignments to $^W in BEGIN blocks then things The main thing to realize is that the statment no warnings qw/numeric/; should disable only numeric warnings and no others. And since the use warnings;
Well, if you do find something, feel free to submit a bug report.
Looks good to me. :-) But if you think a doc patch is required it HTH, -- |
Migrated from rt.perl.org#3269 (status was 'resolved')
Searchable as RT3269$
The text was updated successfully, but these errors were encountered: