'Useless use of a constant in void context' is compile-time but not syntax warning

[p5pRT]

Migrated from rt.perl.org#123665 (status was 'open')

Searchable as RT123665$

[p5pRT]

From @epa

Created by @epa

This program warns 'Useless use of a constant ("a") in void context'​:

#!/usr/bin/perl
use strict;
use warnings;
use 5.018;
use warnings FATAL => 'syntax';
sub x { 'a'; return 0 }
say 'ok';

Since x() is never called the warning must be compile time. Yet
it is not made FATAL.

Now it is not really a syntax error, more a semantic check, so I can
see how it is not included as 'syntax'. I would like to make all
compilation warnings fatal without making run-time warnings fatal.
Perhaps that could be done using a BEGIN block and so on. Could
that feature be added to warnings.pm, as

  use warnings FATAL => 'compilation';

Perl Info

Flags:
    category=core
    severity=low

Site configuration information for perl 5.18.4:

Configured by Red Hat, Inc. at Thu Oct 30 14:55:21 UTC 2014.

Summary of my perl5 (revision 5 version 18 subversion 4) configuration:

  Platform:
    osname=linux, osvers=3.16.3-200.fc20.x86_64, archname=x86_64-linux-thread-multi
    uname='linux buildvm-18.phx2.fedoraproject.org 3.16.3-200.fc20.x86_64 #1 smp wed sep 17 22:34:21 utc 2014 x86_64 x86_64 x86_64 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Dccdlflags=-Wl,--enable-new-dtags -Dlddlflags=-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches  -m64 -mtune=generic -Wl,-z,relro  -Dshrpdir=/usr/lib64 -DDEBUGGING=-g -Dversion=5.18.4 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Darchlib=/usr/lib64/perl5 -Dvendorarch=/usr/lib64/perl5/vendor_perl -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Dusedtrace=/usr/bin/dtrace -Duselargefiles -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin -Dusesitecustomize'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=define, use64bitall=define, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.8.3 20140911 (Red Hat 4.8.3-7)', gccosandvers=''
    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector'
    libpth=/usr/local/lib64 /lib64 /usr/lib64
    libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc -lgdbm_compat
    perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
    libc=, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.18'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,--enable-new-dtags'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro '

Locally applied patches:
    Fedora Patch1: Removes date check, Fedora/RHEL specific
    Fedora Patch3: support for libdir64
    Fedora Patch4: use libresolv instead of libbind
    Fedora Patch5: USE_MM_LD_RUN_PATH
    Fedora Patch6: Skip hostname tests, due to builders not being network capable
    Fedora Patch7: Dont run one io test due to random builder failures
    Fedora Patch9: Fix find2perl to translate ? glob properly (RT#113054)
    Fedora Patch10: Update h2ph(1) documentation (RT#117647)
    Fedora Patch11: Update pod2html(1) documentation (RT#117623)
    Fedora Patch12: Disable ornaments on perl5db AutoTrace tests (RT#118817)
    Fedora Patch14: Do not use system Term::ReadLine::Gnu in tests (RT#118821)
    Fedora Patch15: Define SONAME for libperl.so
    Fedora Patch16: Install libperl.so to -Dshrpdir value
    Fedora Patch18: Fix crash with \\&$glob_copy (RT#119051)
    Fedora Patch19: Fix coreamp.t rand test (RT#118237)
    Fedora Patch20: Reap child in case where exception has been thrown (RT#114722)
    Fedora Patch21: Fix using regular expressions containing multiple code blocks (RT#117917)
    Fedora Patch22: Create site paths by cpan for the first time (CPAN RT#99905)
    Fedora Patch200: Link XS modules to libperl.so with EU::CBuilder on Linux
    Fedora Patch201: Link XS modules to libperl.so with EU::MM on Linux


@INC for perl 5.18.4:
    /home/eda/lib/perl5/
    /usr/local/lib64/perl5
    /usr/local/share/perl5
    /usr/lib64/perl5/vendor_perl
    /usr/share/perl5/vendor_perl
    /usr/lib64/perl5
    /usr/share/perl5
    .


Environment for perl 5.18.4:
    HOME=/home/eda
    LANG=en_GB.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=C
    LC_CTYPE=en_GB.UTF-8
    LC_MESSAGES=en_GB.UTF-8
    LC_MONETARY=en_GB.UTF-8
    LC_NUMERIC=en_GB.UTF-8
    LC_TIME=en_GB.UTF-8
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/home/eda/bin:/home/eda/bin:/usr/local/bin:/usr/bin:/sbin:/usr/sbin:/sbin:/usr/sbin
    PERL5LIB=/home/eda/lib/perl5/
    PERL_BADLANG (unset)
    SHELL=/bin/bash


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

[p5pRT]

From @jkeenan

On Sat Jan 24 00​:06​:21 2015, eda@​waniasset.com wrote​:

This is a bug report for perl from eda@​waniasset.com,
generated with the help of perlbug 1.39 running under perl 5.18.4.

-----------------------------------------------------------------
[Please describe your issue here]

This program warns 'Useless use of a constant ("a") in void context'​:

#!/usr/bin/perl
use strict;
use warnings;
use 5.018;
use warnings FATAL => 'syntax';
sub x { 'a'; return 0 }
say 'ok';

Since x() is never called the warning must be compile time. Yet
it is not made FATAL.

Now it is not really a syntax error, more a semantic check, so I can
see how it is not included as 'syntax'. I would like to make all
compilation warnings fatal without making run-time warnings fatal.
Perhaps that could be done using a BEGIN block and so on. Could
that feature be added to warnings.pm, as

use warnings FATAL => 'compilation';

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 -v | head -2 | tail -1
This is perl 5, version 18, subversion 4 (v5.18.4) built for x86_64-linux

$ perl -Mstrict -E 'use warnings FATAL => q{syntax}; sub x { q{a}; return 0 } say q{ok};'
ok

$ perl -Mstrict -E 'use warnings FATAL => q{void}; sub x { q{a}; return 0 } say q{ok};'
Useless use of a constant ("a") in void context at -e line 1.

Thank you very much.

--
James E Keenan (jkeenan@​cpan.org)

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

@jkeenan - Status changed from 'open' to 'rejected'

[p5pRT]

From @epa

If 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.
I don't want that. But I would like to get an error for the 'void' warnings that can be detected at compile time.
Is that possible?

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http​://www.symanteccloud.com
______________________________________________________________________

[p5pRT]

From Eirik-Berg.Hanssen@allverden.no

On Sat, Jan 24, 2015 at 3​:43 PM, James E Keenan via RT <
perlbug-followup@​perl.org> wrote​:

I would like to make all
compilation warnings fatal without making run-time warnings fatal.
Perhaps that could be done using a BEGIN block and so on. Could
that feature be added to warnings.pm, as

use warnings FATAL => 'compilation';

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'.

  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
run-time warnings nonfatal?

Eirik

[p5pRT]

@jkeenan - Status changed from 'rejected' to 'open'

[p5pRT]

From @haarg

This isn't correct. Enabling fatal void warnings will cause the code
to die at compile time, not runtime.

On Sat, Jan 24, 2015 at 10​:15 AM, Ed Avis <eda@​waniasset.com> wrote​:

If 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.
I don't want that. But I would like to get an error for the 'void' warnings that can be detected at compile time.
Is that possible?

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http​://www.symanteccloud.com
______________________________________________________________________

[p5pRT]

From @epa

Graham Knop <haarg <at> haarg.org> writes​:

Enabling fatal void warnings will cause the code
to die at compile time, not runtime.

Thanks. For some reason I thought this was not the case and that there
were some examples where the check happened at run time (not counting
eval and other tricks). But that could be just because I confused myself
thinking that all compile-time checks belonged under 'syntax'.

I guess then I just need use warnings FATAL => qw(syntax void) to do
what I want. Unless there are further compile-time warnings not
included in that?

--
Ed Avis <eda@​waniasset.com>

[p5pRT]

From Eirik-Berg.Hanssen@allverden.no

On Sat, Jan 24, 2015 at 9​:20 PM, Ed Avis <eda@​waniasset.com> wrote​:

I guess then I just need use warnings FATAL => qw(syntax void) to do
what I want. Unless there are further compile-time warnings not
included in that?

  Oh, there's more.

  What's more, among "misc" warnings, some are compile-time, and some are
run-time​:

$ perl -Mwarnings=misc -E 'BEGIN { say "<compiletime>" } say "<runtime>";
our($x); our $x; %x = @​ARGV; say "</runtime>"; BEGIN { say "</compiletime>"
}' 1
<compiletime>
"our" variable $x redeclared at -e line 1.
</compiletime>
<runtime>
Odd number of elements in hash assignment at -e line 1.
</runtime>
$

  So, how to fatalize only the one? I have no clue.

Eirik

[p5pRT]

From @cpansprout

On Sat Jan 24 12​:55​:36 2015, Eirik-Berg.Hanssen@​allverden.no wrote​:

On Sat, Jan 24, 2015 at 9​:20 PM, Ed Avis <eda@​waniasset.com> wrote​:

I guess then I just need use warnings FATAL => qw(syntax void) to do
what I want. Unless there are further compile-time warnings not
included in that?

Oh, there's more.

What's more, among "misc" warnings, some are compile-time, and some are
run-time​:

$ perl -Mwarnings=misc -E 'BEGIN { say "<compiletime>" } say "<runtime>";
our($x); our $x; %x = @​ARGV; say "</runtime>"; BEGIN { say "</compiletime>"
}' 1
<compiletime>
"our" variable $x redeclared at -e line 1.
</compiletime>
<runtime>
Odd number of elements in hash assignment at -e line 1.
</runtime>
$

So, how to fatalize only the one? I have no clue.

Hmmm. With current perl, you can do something like this​:

BEGIN { $SIG{__WARN__} = sub { die shift } }
...
BEGIN { undef $SIG{__WARN__} }

But that clobbers any existing handler.

--

Father Chrysostomos

[p5pRT]

From @cpansprout

On Sat Jan 24 17​:30​:25 2015, sprout wrote​:

On Sat Jan 24 12​:55​:36 2015, Eirik-Berg.Hanssen@​allverden.no wrote​:

On Sat, Jan 24, 2015 at 9​:20 PM, Ed Avis <eda@​waniasset.com> wrote​:

I guess then I just need use warnings FATAL => qw(syntax void) to
do
what I want. Unless there are further compile-time warnings not
included in that?

Oh, there's more.

What's more, among "misc" warnings, some are compile-time, and some
are
run-time​:

$ perl -Mwarnings=misc -E 'BEGIN { say "<compiletime>" } say
"<runtime>";
our($x); our $x; %x = @​ARGV; say "</runtime>"; BEGIN { say
"</compiletime>"
}' 1
<compiletime>
"our" variable $x redeclared at -e line 1.
</compiletime>
<runtime>
Odd number of elements in hash assignment at -e line 1.
</runtime>
$

So, how to fatalize only the one? I have no clue.

Hmmm. With current perl, you can do something like this​:

BEGIN { $SIG{__WARN__} = sub { die shift } }
...
BEGIN { undef $SIG{__WARN__} }

But that clobbers any existing handler.

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

[p5pRT]

From @epa

Father Chrysostomos via RT <perlbug-followup <at> perl.org> writes​:

The thing is, warnings.pm is lexical, and this compile-time/run-time
distinction is orthogonal to lexical scoping.

It is orthogonal; but equally the other distinctions supported by
warnings.pm ('void', 'syntax', etc) are orthogonal to scoping.

I expect that every warning currently issued by perl can be categorized
as either compile-time or run-time (ignoring the question of eval(), which
can convert a compile-time warning to a run-time one, and constant folding,
which may do the opposite).

(If I'm wrong and there are warnings which can fire at either stage, the
picture gets a bit more complicated. But assuming not...)

Then use warnings FATAL => 'compile-time' would turn on all warnings
categorized as compile-time warnings. This would effectively be syntactic
sugar for qw(void syntax etc).

The advantage is that the programmer wouldn't have to remember the exact
incantation to list all compile-time warnings and no run-time ones (and that
new compile-time warnings in later perl versions would automatically be
added to the list).

(There has often been discussion on p5p of the dangers of fatal warnings.
I could expand on the reasons why I believe that fatal compile-time warnings
are a useful tool while still wanting to avoid going kaboom at run time.)

--
Ed Avis <eda@​waniasset.com>

[p5pRT]

From @haarg

On Sun, Jan 25, 2015 at 1​:11 PM, Ed Avis <eda@​waniasset.com> wrote​:

It is orthogonal; but equally the other distinctions supported by
warnings.pm ('void', 'syntax', etc) are orthogonal to scoping.

I expect that every warning currently issued by perl can be categorized
as either compile-time or run-time (ignoring the question of eval(), which
can convert a compile-time warning to a run-time one, and constant folding,
which may do the opposite).

If you are speaking of the individual warnings, probably. But if you
are talking about categories this isn't the case.

(If I'm wrong and there are warnings which can fire at either stage, the
picture gets a bit more complicated. But assuming not...)

Then use warnings FATAL => 'compile-time' would turn on all warnings
categorized as compile-time warnings. This would effectively be syntactic
sugar for qw(void syntax etc).

The advantage is that the programmer wouldn't have to remember the exact
incantation to list all compile-time warnings and no run-time ones (and that
new compile-time warnings in later perl versions would automatically be
added to the list).

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.
The first is compile time, warning about having code after an exec
call, because the code will never be reached. The second is a runtime
warning for if the exec call fails, such as the file given not
existing. This also impacts system. Normally with system, if the
exec call fails it will issue a warning and then exit the sub process.
The extra fun bit though is that with fatal warnings, the warning is
thrown as an error and the exit isn't reached. If that fatalized
warning is caught with an eval, you now have two processes running
where you thought you only had one.