'Useless use of a constant in void context' is compile-time but not syntax warning #14442
Comments
From @epaCreated by @epaThis program warns 'Useless use of a constant ("a") in void context': #!/usr/bin/perl Since x() is never called the warning must be compile time. Yet Now it is not really a syntax error, more a semantic check, so I can use warnings FATAL => 'compilation'; Perl Info |
From @jkeenanOn Sat Jan 24 00:06:21 2015, eda@waniasset.com wrote:
There is no bug here. You are using the wrong category of warnings. The case you describe is covered by category 'void', not category 'syntax'. See: 'perldoc perldiag'. ##### $ perl -Mstrict -E 'use warnings FATAL => q{syntax}; sub x { q{a}; return 0 } say q{ok};' $ perl -Mstrict -E 'use warnings FATAL => q{void}; sub x { q{a}; return 0 } say q{ok};' Thank you very much. -- |
|
The RT System itself - Status changed from 'new' to 'open' |
|
@jkeenan - Status changed from 'open' to 'rejected' |
From @epaIf the program has use warnings FATAL => q{void}; then it can compile but later die at run time when a particular line of code is reached. ______________________________________________________________________ |
From Eirik-Berg.Hanssen@allverden.noOn Sat, Jan 24, 2015 at 3:43 PM, James E Keenan via RT <
It's not a bug report, but it is a feature request. A wishlist item. ... with an unfortunate subject, but still ... Seriously, how would one make all compile-time warnings fatal, but leave Eirik |
|
@jkeenan - Status changed from 'rejected' to 'open' |
From @haargThis isn't correct. Enabling fatal void warnings will cause the code On Sat, Jan 24, 2015 at 10:15 AM, Ed Avis <eda@waniasset.com> wrote:
|
From @epaGraham Knop <haarg <at> haarg.org> writes:
Thanks. For some reason I thought this was not the case and that there I guess then I just need use warnings FATAL => qw(syntax void) to do -- |
From Eirik-Berg.Hanssen@allverden.noOn Sat, Jan 24, 2015 at 9:20 PM, Ed Avis <eda@waniasset.com> wrote:
Oh, there's more. What's more, among "misc" warnings, some are compile-time, and some are $ perl -Mwarnings=misc -E 'BEGIN { say "<compiletime>" } say "<runtime>"; So, how to fatalize only the one? I have no clue. Eirik |
From @cpansproutOn Sat Jan 24 12:55:36 2015, Eirik-Berg.Hanssen@allverden.no wrote:
Hmmm. With current perl, you can do something like this: BEGIN { $SIG{__WARN__} = sub { die shift } } But that clobbers any existing handler. -- Father Chrysostomos |
From @cpansproutOn Sat Jan 24 17:30:25 2015, sprout wrote:
The thing is, warnings.pm is lexical, and this compile-time/run-time distinction is orthogonal to lexical scoping. I don‘t see how we could shoehorn the feature cleanly into warnings.pm. (Having $^W and warnings.pm already makes things undesirably complex. You can’t please everybody.) -- Father Chrysostomos |
From @epaFather Chrysostomos via RT <perlbug-followup <at> perl.org> writes:
It is orthogonal; but equally the other distinctions supported by I expect that every warning currently issued by perl can be categorized (If I'm wrong and there are warnings which can fire at either stage, the Then use warnings FATAL => 'compile-time' would turn on all warnings The advantage is that the programmer wouldn't have to remember the exact (There has often been discussion on p5p of the dangers of fatal warnings. -- |
From @haargOn Sun, Jan 25, 2015 at 1:11 PM, Ed Avis <eda@waniasset.com> wrote:
If you are speaking of the individual warnings, probably. But if you
There currently is no incantation you can use to only get compile time warnings. For my favorite example of this, the exec category has two warnings. |
From @epaYes, I meant that each individual warning is either compile-time or run-time. ______________________________________________________________________ |
From arisadam25@mail.comThe functions in this section can serve as terms in an expression. Why does use bigint; 1; warn in void context? $ perl -c -we'1 while sub_with_side_effects();' $ perl -c -we'use bigint; 1 while sub_with_side_effects();' OK, so - from the comments - you're comparing two arrays. Presumably inside your loop you're doing something like: if ( $name[$j] == $name_mod[$k] ) { So my suggestion would be - don't do it like that: for ( my $index = 0; $index < @name and $index < @name_mod; $index++ ) { Or perhaps: each_array my $ea = each_array(@name, @name_mod); |
From [Unknown Contact. See original ticket]The functions in this section can serve as terms in an expression. Why does use bigint; 1; warn in void context? $ perl -c -we'1 while sub_with_side_effects();' $ perl -c -we'use bigint; 1 while sub_with_side_effects();' OK, so - from the comments - you're comparing two arrays. Presumably inside your loop you're doing something like: if ( $name[$j] == $name_mod[$k] ) { So my suggestion would be - don't do it like that: for ( my $index = 0; $index < @name and $index < @name_mod; $index++ ) { Or perhaps: each_array my $ea = each_array(@name, @name_mod); |
From @AbigailOn Wed, Sep 14, 2016 at 05:37:43AM -0700, Redfred Garett via RT wrote:
The answer to the second question is simple: it's executed in void As for the first part: Normally, perl warns if it sees a literal in However, under "use bigint", what looks like a literal 1 to the reader To see the difference: $ perl -MDevel::Peel -we 'Dump 1'; $ perl -MDevel::Peel -we 'use bigint; Dump 1'; Regards, Abigail |
From Eirik-Berg.Hanssen@allverden.noOn Thu, Sep 15, 2016 at 11:10 AM, Abigail <abigail@abigail.be> wrote:
[snip]
Um, that's just the thing – it does warn: $ perl -we 'use bigint; 1' Compare: $ perl -we '1;' -e '2;' -e 'use bigint; 1;' -e2 The missing warning from the first literal is, as you said, the special The warning from the penultimate literal shows that the special case for Moreover, the warning from either of the last two literals also shows I'm not saying perl is doing the wrong thing in general to warn for Eirik |
|
Could I ask whoever triages bugs to have another look at this one? It seems to have got a bit jumbled up with comments from an unrelated bug about bigint added to the end. I believe that my comment on 2015-01-26 is the last one that belongs and the others can be moved to a new bug. |
Migrated from rt.perl.org#123665 (status was 'open')
Searchable as RT123665$
The text was updated successfully, but these errors were encountered: