perllexwarn should be integrated into warnings #11380

p5pRT · 2011-05-24T23:47:25Z

Migrated from rt.perl.org#91578 (status was 'resolved')

Searchable as RT91578$

p5pRT · 2011-05-24T23:47:26Z

From @mauke

Created by @mauke

Hi,

I think most of 'perldoc perllexwarn' should be integrated into
'perldoc warnings' because that's the obvious place to look for
information on how to use warnings.

Currently the 'use warnings' interface, including how to make
warnings fatal and the list of available warning categories, is only
documented in perllexwarn. This was a surprise to me.

Perl Info


Flags:
    category=library
    severity=wishlist
    module=warnings

This perlbug was built using Perl 5.12.1 - Thu Jun  3 20:09:15 CEST 2010
It is being executed now by  Perl 5.14.0 - Sun May 15 10:47:31 CEST 2011.

Site configuration information for perl 5.14.0:

Configured by mauke at Sun May 15 10:47:31 CEST 2011.

Summary of my perl5 (revision 5 version 14 subversion 0) configuration:
   
  Platform:
    osname=linux, osvers=2.6.37-gentoo-r4, archname=i686-linux
    uname='linux nora 2.6.37-gentoo-r4 #3 preempt thu may 5 20:36:24 cest 2011 i686 amd athlon(tm) 64 processor 3200+ authenticamd gnulinux '
    config_args=''
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O2 -march=native',
    cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
    ccversion='', gccversion='4.5.1', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -fstack-protector -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat
    perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
    libc=/lib/libc-2.11.3.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version='2.11.3'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
    cccdlflags='-fPIC', lddlflags='-shared -O2 -march=native -L/usr/local/lib -fstack-protector'

Locally applied patches:
    SAVEARGV0 - disable magic open in <ARGV>


@INC for perl 5.14.0:
    /home/mauke/usr/local/lib/perl5/site_perl/5.14.0/i686-linux
    /home/mauke/usr/local/lib/perl5/site_perl/5.14.0
    /home/mauke/usr/local/lib/perl5/5.14.0/i686-linux
    /home/mauke/usr/local/lib/perl5/5.14.0
    /home/mauke/usr/local/lib/perl5/site_perl/5.12.3
    /home/mauke/usr/local/lib/perl5/site_perl/5.12.2
    /home/mauke/usr/local/lib/perl5/site_perl/5.12.1
    /home/mauke/usr/local/lib/perl5/site_perl
    .


Environment for perl 5.14.0:
    HOME=/home/mauke
    LANG=en_US.UTF-8
    LANGUAGE (unset)
    LC_COLLATE=POSIX
    LD_LIBRARY_PATH=/home/mauke/usr/local/lib
    LOGDIR (unset)
    PATH=/home/mauke/usr/local/bin:/usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/i686-pc-linux-gnu/gcc-bin/4.4.5:/opt/sun-jdk-1.4.2.13/bin:/opt/sun-jdk-1.4.2.13/jre/bin:/opt/sun-jdk-1.4.2.13/jre/javaws:/opt/dmd/bin:/usr/games/bin
    PERL_BADLANG (unset)
    PERL_UNICODE=SAL
    SHELL=/bin/bash

p5pRT · 2011-12-17T03:10:13Z

From @jkeenan

On Tue May 24 16:47:26 2011, l.mai@web.de wrote:

I think most of 'perldoc perllexwarn' should be integrated into
'perldoc warnings' because that's the obvious place to look for
information on how to use warnings.

Currently the 'use warnings' interface, including how to make
warnings fatal and the list of available warning categories, is only
documented in perllexwarn. This was a surprise to me.

Since no patch was supplied, someone would have to prepare one in order
to take action on this ticket.

Before anyone embarks on that, may I ask whether there is merit to the
general idea? Do people feel that 'perllexwarn' should be merged into
'warnings'?

Thank you very much.
Jim Keenan

p5pRT · 2011-12-17T03:10:14Z

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

p5pRT · 2013-02-03T20:07:24Z

From @jkeenan

On Fri Dec 16 19:10:13 2011, jkeenan wrote:

On Tue May 24 16:47:26 2011, l.mai@web.de wrote:

I think most of 'perldoc perllexwarn' should be integrated into
'perldoc warnings' because that's the obvious place to look for
information on how to use warnings.

Currently the 'use warnings' interface, including how to make
warnings fatal and the list of available warning categories, is only
documented in perllexwarn. This was a surprise to me.

Since no patch was supplied, someone would have to prepare one in order
to take action on this ticket.

Before anyone embarks on that, may I ask whether there is merit to the
general idea? Do people feel that 'perllexwarn' should be merged into
'warnings'?

There has been no response to these questions in 14 months. Closing ticket.

Thank you very much.
Jim Keenan

p5pRT · 2013-02-03T20:07:25Z

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

p5pRT · 2013-02-04T17:33:19Z

From @iabyn

On Sun, Feb 03, 2013 at 12:07:25PM -0800, James E Keenan via RT wrote:

On Fri Dec 16 19:10:13 2011, jkeenan wrote:

On Tue May 24 16:47:26 2011, l.mai@web.de wrote:

I think most of 'perldoc perllexwarn' should be integrated into
'perldoc warnings' because that's the obvious place to look for
information on how to use warnings.

Currently the 'use warnings' interface, including how to make
warnings fatal and the list of available warning categories, is only
documented in perllexwarn. This was a surprise to me.

Since no patch was supplied, someone would have to prepare one in order
to take action on this ticket.

Before anyone embarks on that, may I ask whether there is merit to the
general idea? Do people feel that 'perllexwarn' should be merged into
'warnings'?

There has been no response to these questions in 14 months. Closing ticket.

I think the idea may have merit. The ticket should be left open.

--
Never do today what you can put off till tomorrow.

p5pRT · 2013-02-05T00:23:42Z

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

p5pRT · 2013-02-05T02:47:31Z

From @rjbs

* Dave Mitchell <davem@iabyn.com> [2013-02-04T12:32:35]

I think the idea may have merit. The ticket should be left open.

Agreed. I will look at adding this to a META ticket RSN. I have often felt
that perllexwarn was too obscure.

--
rjbs

p5pRT · 2013-02-07T14:59:26Z

From @ap

* Ricardo Signes <perl.p5p@rjbs.manxome.org> [2013-02-05 03:50]:

I have often felt that perllexwarn was too obscure.

The obscurity of perllexwarn is always accompanied by another issue, for
me, which suggests a related idea. Namely, when I want to disable some
particular warning, I always first have to remember that the overview of
categories is in perllexwarn, then I had to eyeball the categories and
guess which one is the one that will disable the warning in question.

I wish I could just look it up.

We already have a list of all the warnings in perldiag.

How about adding its category to the description of each warning there?
(And should I file a separate bug for that if so?)

Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>

p5pRT · 2013-02-07T15:02:11Z

From @rjbs

* Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-02-07T09:58:44]

We already have a list of all the warnings in perldiag.

How about adding its category to the description of each warning there?
(And should I file a separate bug for that if so?)

Here is an example warning from perldiag:

Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a
mistake. To suppress this warning assign a defined value to your
variables.

The "uninitialized" is the category. In light of this, I don't understand your
email. Are there entries that lack the category? Did you mean we should do
something different? Please elaborate.

--
rjbs

p5pRT · 2013-02-07T15:22:11Z

From @demerphq

On 7 February 2013 16:01, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:

* Aristotle Pagaltzis <pagaltzis@gmx.de> [2013-02-07T09:58:44]

We already have a list of all the warnings in perldiag.

How about adding its category to the description of each warning there?
(And should I file a separate bug for that if so?)

Here is an example warning from perldiag:

Use of uninitialized value%s
(W uninitialized) An undefined value was used as if it were already
defined. It was interpreted as a "" or a 0, but maybe it was a
mistake. To suppress this warning assign a defined value to your
variables.

The "uninitialized" is the category. In light of this, I don't understand your
email. Are there entries that lack the category? Did you mean we should do
something different? Please elaborate.

I bet not that many people use 'splain, nor "use diagnostics".

Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

p5pRT · 2013-02-07T19:44:27Z

From @xdg

On Thu, Feb 7, 2013 at 10:01 AM, Ricardo Signes
<perl.p5p@rjbs.manxome.org> wrote:

The "uninitialized" is the category. In light of this, I don't understand your
email. Are there entries that lack the category? Did you mean we should do
something different? Please elaborate.

There is a somewhat obscure paragraph about it at the top of perldiag:

If a message can be controlled by the "warnings" pragma, its warning
category is included with the classification letter in the description
below.

I clarified it with an example in commit
466416e:

-below.
+below. E.g. C<(W closed)> means a warning in the C<closed> category.

--
David Golden <xdg@xdg.me>
Take back your inbox! → http://www.bunchmail.com/
Twitter/IRC: @xdg

p5pRT · 2014-01-31T15:04:16Z

From @rjbs

Unless there is an objection, I will work on this. I think this would be a good change.
--
rjbs

p5pRT · 2014-03-14T13:24:00Z

From @rjbs

I have pushed rjbs/lexwarn to perl5.git, but I'm not 100% happy with it.

The text could probably do with a bit more integration to smooth the two documents together, but that's not the problem.

I added this commit:

commit efd12ca
Author: Ricardo Signes <rjbs@cpan.org>
Date: Fri Mar 14 12:33:50 2014 +0100

ABSURD: hide the =head1 NAME in regen/warnings.pl

This wasn't needed before I began this branch.
Why is it needed now?

after c0d65a4 and prior to that commit, podcheck complaints that two documents have a NAME of warnings: regen/warnings.pl and lib/warnings.pm — despite the fact that my work does NOT introduce this name to either document!

I've added a workaround, but I don't like it, because I am not sure why it's needed. Anybody see what's up here?

--
rjbs

p5pRT · 2014-03-15T04:43:31Z

From @khwilliamson

On 03/14/2014 07:24 AM, Ricardo SIGNES via RT wrote:

I have pushed rjbs/lexwarn to perl5.git, but I'm not 100% happy with it.

The text could probably do with a bit more integration to smooth the two documents together, but that's not the problem.

I added this commit:

commit efd12ca
Author: Ricardo Signes <rjbs@cpan.org>
Date: Fri Mar 14 12:33:50 2014 +0100
 ABSURD&#8203;: hide the =head1 NAME in regen/warnings\.pl

 This wasn't needed before I began this branch\.
 Why is it needed now?
after c0d65a4 and prior to that commit, podcheck complaints that two documents have a NAME of warnings: regen/warnings.pl and lib/warnings.pm — despite the fact that my work does NOT introduce this name to either document!

I've added a workaround, but I don't like it, because I am not sure why it's needed. Anybody see what's up here?

I took a look at this. regen/warnings.pl generates lib/warnings.pm. The
latter contains a pod; the former contains text that is turned into the
pod. The problem is that it is hard to know what is a legitimate pod,
and what is the skeleton for generating a pod. Thus it looks like both
are pods, with the same NAME. Since it is illegal to have two pods with
the same name (as that field is what they are linked to by), podcheck.t
generates a warning.

This has come up before, and the solution has been to add the generator
file to the exception list in podcheck.t:

# Not really pods, but can look like them.
my %excluded_files

That seems to be a better solution than the one you are unhappy with.

I haven't investigated why it wasn't a problem before your branch. My
guess, without looking, comes from knowing that podcheck.t takes a few
steps when this conflict occurs to try to resolve it without raising a
warning. I suspect therefore that before your changes, those steps were
sufficient, and that something you did caused them to become insufficient.

p5pRT · 2014-03-15T09:10:00Z

From @rjbs

* Karl Williamson <public@khwilliamson.com> [2014-03-15T00:44:09]

This has come up before, and the solution has been to add the
generator file to the exception list in podcheck.t:

# Not really pods, but can look like them.
my %excluded_files

Thanks, that's a better solution.

I haven't investigated why it wasn't a problem before your branch.

I may look more later. I guess I don't need the answer, but it will keep me up
at night. :)

--
rjbs

p5pRT · 2014-03-20T12:02:58Z

From @rjbs

This has been merged!

--
rjbs

p5pRT · 2014-03-20T12:02:59Z

@rjbs - Status changed from 'open' to 'resolved'

p5pRT closed this as completed Mar 20, 2014

p5pRT added Wishlist affects-5.14 distro-Linux type-library labels Oct 19, 2019

tonycoz mentioned this issue Apr 11, 2024

[META] tickets requiring no C, perlguts, or OS expertise #12717

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

perllexwarn should be integrated into warnings #11380

perllexwarn should be integrated into warnings #11380

p5pRT commented May 24, 2011

p5pRT commented May 24, 2011

p5pRT commented Dec 17, 2011

p5pRT commented Dec 17, 2011

p5pRT commented Feb 3, 2013

p5pRT commented Feb 3, 2013

p5pRT commented Feb 4, 2013

p5pRT commented Feb 5, 2013

p5pRT commented Feb 5, 2013

p5pRT commented Feb 7, 2013

p5pRT commented Feb 7, 2013

p5pRT commented Feb 7, 2013

p5pRT commented Feb 7, 2013

p5pRT commented Jan 31, 2014

p5pRT commented Mar 14, 2014

p5pRT commented Mar 15, 2014

p5pRT commented Mar 15, 2014

p5pRT commented Mar 20, 2014

p5pRT commented Mar 20, 2014

perllexwarn should be integrated into warnings #11380

perllexwarn should be integrated into warnings #11380

Comments

p5pRT commented May 24, 2011

p5pRT commented May 24, 2011

From @mauke

Created by @mauke

p5pRT commented Dec 17, 2011

From @jkeenan

p5pRT commented Dec 17, 2011

p5pRT commented Feb 3, 2013

From @jkeenan

p5pRT commented Feb 3, 2013

p5pRT commented Feb 4, 2013

From @iabyn

p5pRT commented Feb 5, 2013

p5pRT commented Feb 5, 2013

From @rjbs

p5pRT commented Feb 7, 2013

From @ap

p5pRT commented Feb 7, 2013

From @rjbs

p5pRT commented Feb 7, 2013

From @demerphq

p5pRT commented Feb 7, 2013

From @xdg

p5pRT commented Jan 31, 2014

From @rjbs

p5pRT commented Mar 14, 2014

From @rjbs

p5pRT commented Mar 15, 2014

From @khwilliamson

p5pRT commented Mar 15, 2014

From @rjbs

p5pRT commented Mar 20, 2014

From @rjbs

p5pRT commented Mar 20, 2014