Skip Menu |
Report information
Id: 108778
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: sprout <sprout [at] cpan.org>
Cc:
AdminCc:

Operating System: darwin
PatchStatus: (no value)
Severity: low
Type: library
Perl Version: 5.15.6
Fixed In: (no value)



Subject: no warnings "module name"
Date: Sun, 22 Jan 2012 12:52:00 -0800
To: perlbug [...] perl.org
From: Father Chrysostomos <sprout [...] cpan.org>
perldiag lists some warnings in the ‘overload’ category. What is not documented anywhere is that this is a custom category registered by overload.pm. The result: $ ./perl -Ilib -e 'use warnings; no warnings "overload"; ...' Unknown warnings category 'overload' at -e line 1 BEGIN failed--compilation aborted at -e line 1. If I load overload.pm first, it works fine. While this could be argued as not being a bug, it just doesn’t feel right. It should be possible to disable a warnings category before it is registered, because usually the code disabling the warnings category doesn’t know when it is registered. --- Flags: category=library severity=low --- Site configuration information for perl 5.15.6: Configured by sprout at Mon Jan 16 08:41:41 PST 2012. Summary of my perl5 (revision 5 version 15 subversion 6) configuration: Commit id: bdd2b37b5c6133a3b8647bb19d63f9598457d4d4 Platform: osname=darwin, osvers=10.5.0, archname=darwin-2level uname='darwin pint.local 10.5.0 darwin kernel version 10.5.0: fri nov 5 23:20:39 pdt 2010; root:xnu-1504.9.17~1release_i386 i386 ' config_args='-de -Dusedevel -DDEBUGGING' 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='cc', ccflags ='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include', optimize='-O3 -g', cppflags='-fno-common -DPERL_DARWIN -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5664)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=, so=dylib, useshrplib=false, libperl=libperl.a gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -bundle -undefined dynamic_lookup -L/usr/local/lib -fstack-protector' Locally applied patches: --- @INC for perl 5.15.6: /usr/local/lib/perl5/site_perl/5.15.6/darwin-2level /usr/local/lib/perl5/site_perl/5.15.6 /usr/local/lib/perl5/5.15.6/darwin-2level /usr/local/lib/perl5/5.15.6 /usr/local/lib/perl5/site_perl . --- Environment for perl 5.15.6: DYLD_LIBRARY_PATH (unset) HOME=/Users/sprout LANG=en_US.UTF-8 LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin:/usr/local/bin PERL_BADLANG (unset) SHELL=/bin/bash
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 960b
On Sun Jan 22 12:52:17 2012, sprout wrote: Show quoted text
> perldiag lists some warnings in the ‘overload’ category. What is not > documented anywhere is that this is a custom category registered by > overload.pm. > > The result: > > $ ./perl -Ilib -e 'use warnings; no warnings "overload"; ...' > Unknown warnings category 'overload' at -e line 1 > BEGIN failed--compilation aborted at -e line 1. > > If I load overload.pm first, it works fine. > > While this could be argued as not being a bug, it just doesn’t feel > right. It should be possible to disable a warnings category before > it is registered, because usually the code disabling the warnings > category doesn’t know when it is registered.
Also, ‘use warnings’ doesn’t enable overload warnings unless overload.pm is already loaded. So BEGIN { $^W = 1 } will actually give *more* warnings than ‘use warnings; use overload ...’. See also #108870. -- Father Chrysostomos
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Date: Wed, 15 Nov 2017 09:59:15 +0000
Subject: Re: [perl #108778] no warnings "module name"
Download (untitled) / with headers
text/plain 1.3k
Father Chrysostomos wrote: Show quoted text
>It should be possible to disable a warnings category before it is >registered,
We could implement that by implicitly registering any warnings category that gets mentioned in order to assign a slot in the bitset. But accepting not-yet-registered would mean losing all protection on warning pragmata against typos and naming mistakes. If we were to do that, 'use warnings "nuemric"' and 'use warnings "syscall"' *would* proliferate. When the type is on a "use warnings", it means the programmer wouldn't get warnings that ey thought ey would get, which would encourage the development of subtle bugs. So I think we have to insist on explicit registration. A module that knows it's going to refer to a non-core warnings category, and doesn't know that it'll already be registered, could explicitly register the category itself. Registration is idempotent, so there's no problem of clashing with the `real' registration. It does mean that modules need to be aware of which categories they mention are non-core, but that's not too bad a downside for a relatively rare requirement. Show quoted text
>Also, `use warnings' doesn't enable overload warnings unless overload.pm >is already loaded.
That sounds more like a real bug. It needs to be addressed by changing the treatment of short bitsets (not containing whichever bit we're trying to look at). -zefram
Date: Wed, 15 Nov 2017 18:33:45 +0000
Subject: Re: [perl #108778] no warnings "module name"
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Download (untitled) / with headers
text/plain 385b
I wrote: Show quoted text
>That sounds more like a real bug. It needs to be addressed by changing >the treatment of short bitsets (not containing whichever bit we're trying >to look at).
Fixed in commit 006c1a1dbd541b84351332b0d315508f789f3bd1. It turned out to be more involved than I expected, because the bits for the "all" category had some ugly exceptional behaviour, which had to go. -zefram
From: Father Chrysostomos <sprout [...] cpan.org>
To: perlbug-followup [...] perl.org
Subject: Re: [perl #108778] no warnings "module name"
Date: Sun, 19 Nov 2017 12:07:59 -0800
Download (untitled) / with headers
text/plain 2.1k
On Nov 15, 2017, at 1:59 AM, Zefram via RT <perlbug-followup@perl.org> wrote: Show quoted text
> Father Chrysostomos wrote:
>> It should be possible to disable a warnings category before it is >> registered,
> > We could implement that by implicitly registering any warnings > category that gets mentioned in order to assign a slot in the bitset. > But accepting not-yet-registered would mean losing all protection > on warning pragmata against typos and naming mistakes. If we were > to do that, 'use warnings "nuemric"' and 'use warnings "syscall"' > *would* proliferate. When the type is on a "use warnings", it means > the programmer wouldn't get warnings that ey thought ey would get, > which would encourage the development of subtle bugs.
Yes, that’s prceiesly why I didn’t go aehad and imlpemnet it. (Sutides sohw that, as long as the frsit and lsat ltteres are in the rihgt plcae, poelpe can stlil raed qucilky.) It was a conundrum I did not know how to resolve. Show quoted text
> So I think we have to insist on explicit registration. A module that > knows it's going to refer to a non-core warnings category, and doesn't > know that it'll already be registered, could explicitly register the > category itself.
I want to avoid this, though: use warnings; { package # hide from PAUSE Hash::Util; use warnings::register } no warnings qw 'once Hash::Util'; or: use warnings; BEGIN { warnings::register_categories "Hash::Util" } no warnings qw 'once Hash::Util'; Do you think it would be reasonable to add a REGISTER directive, similar to FATAL? use warnings; no warnings 'once' , REGISTER => "Hash::Util"; Show quoted text
> Registration is idempotent, so there's no problem of > clashing with the `real' registration. It does mean that modules need > to be aware of which categories they mention are non-core, but that's > not too bad a downside for a relatively rare requirement. >
>> Also, `use warnings' doesn't enable overload warnings unless overload.pm >> is already loaded.
> > That sounds more like a real bug. It needs to be addressed by changing > the treatment of short bitsets (not containing whichever bit we're trying > to look at).
Thank you for fixing that.
Subject: Re: [perl #108778] no warnings "module name"
To: Father Chrysostomos <sprout [...] cpan.org>, perlbug-followup [...] perl.org
From: Sawyer X <xsawyerx [...] gmail.com>
Date: Sun, 19 Nov 2017 21:46:58 +0100
Download (untitled) / with headers
text/plain 2.4k
On 11/19/2017 09:07 PM, Father Chrysostomos wrote: Show quoted text
> On Nov 15, 2017, at 1:59 AM, Zefram via RT <perlbug-followup@perl.org> wrote: >
>> Father Chrysostomos wrote:
>>> It should be possible to disable a warnings category before it is >>> registered,
>> We could implement that by implicitly registering any warnings >> category that gets mentioned in order to assign a slot in the bitset. >> But accepting not-yet-registered would mean losing all protection >> on warning pragmata against typos and naming mistakes. If we were >> to do that, 'use warnings "nuemric"' and 'use warnings "syscall"' >> *would* proliferate. When the type is on a "use warnings", it means >> the programmer wouldn't get warnings that ey thought ey would get, >> which would encourage the development of subtle bugs.
> Yes, that’s prceiesly why I didn’t go aehad and imlpemnet it. (Sutides sohw that, as long as the frsit and lsat ltteres are in the rihgt plcae, poelpe can stlil raed qucilky.) It was a conundrum I did not know how to resolve. >
>> So I think we have to insist on explicit registration. A module that >> knows it's going to refer to a non-core warnings category, and doesn't >> know that it'll already be registered, could explicitly register the >> category itself.
> I want to avoid this, though: > > use warnings; > { package # hide from PAUSE > Hash::Util; use warnings::register } > no warnings qw 'once Hash::Util'; > > or: > > use warnings; > BEGIN { warnings::register_categories "Hash::Util" } > no warnings qw 'once Hash::Util';
Please don't. This mixes the import specification for warning categories with classes. These are distinct things that should be kept apart. Show quoted text
> Do you think it would be reasonable to add a REGISTER directive, similar to FATAL? > > use warnings; > no warnings 'once' , REGISTER => "Hash::Util";
Not as bad, but worries me about action at a distance. Show quoted text
>
>> Registration is idempotent, so there's no problem of >> clashing with the `real' registration. It does mean that modules need >> to be aware of which categories they mention are non-core, but that's >> not too bad a downside for a relatively rare requirement. >>
>>> Also, `use warnings' doesn't enable overload warnings unless overload.pm >>> is already loaded.
>> That sounds more like a real bug. It needs to be addressed by changing >> the treatment of short bitsets (not containing whichever bit we're trying >> to look at).
> Thank you for fixing that.
I'll second that. :)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 2.3k
On Sun, 19 Nov 2017 12:47:25 -0800, xsawyerx@gmail.com wrote: Show quoted text
> > > On 11/19/2017 09:07 PM, Father Chrysostomos wrote:
> > On Nov 15, 2017, at 1:59 AM, Zefram via RT <perlbug- > > followup@perl.org> wrote: > >
> >> Father Chrysostomos wrote:
> >>> It should be possible to disable a warnings category before it is > >>> registered,
> >> We could implement that by implicitly registering any warnings > >> category that gets mentioned in order to assign a slot in the > >> bitset. > >> But accepting not-yet-registered would mean losing all protection > >> on warning pragmata against typos and naming mistakes. If we were > >> to do that, 'use warnings "nuemric"' and 'use warnings "syscall"' > >> *would* proliferate. When the type is on a "use warnings", it means > >> the programmer wouldn't get warnings that ey thought ey would get, > >> which would encourage the development of subtle bugs.
> > Yes, that’s prceiesly why I didn’t go aehad and imlpemnet it. > > (Sutides sohw that, as long as the frsit and lsat ltteres are in the > > rihgt plcae, poelpe can stlil raed qucilky.) It was a conundrum I > > did not know how to resolve. > >
> >> So I think we have to insist on explicit registration. A module > >> that > >> knows it's going to refer to a non-core warnings category, and > >> doesn't > >> know that it'll already be registered, could explicitly register the > >> category itself.
> > I want to avoid this, though: > > > > use warnings; > > { package # hide from PAUSE > > Hash::Util; use warnings::register } > > no warnings qw 'once Hash::Util'; > > > > or: > > > > use warnings; > > BEGIN { warnings::register_categories "Hash::Util" } > > no warnings qw 'once Hash::Util';
> > Please don't. This mixes the import specification for warning > categories > with classes. These are distinct things that should be kept apart.
I think you are missing the fact that these two examples are what currently work to get around the problem. We already conflate package names with warning categories. Show quoted text
> > Do you think it would be reasonable to add a REGISTER directive, > > similar to FATAL? > > > > use warnings; > > no warnings 'once' , REGISTER => "Hash::Util";
> > Not as bad, but worries me about action at a distance.
Warning registrations are necessarily global. This is no more action at a distance than the existing: package Foo; use warnings::register; -- Father Chrysostomos
Date: Mon, 20 Nov 2017 09:55:56 +0000
To: perl5-porters [...] perl.org
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #108778] no warnings "module name"
Download (untitled) / with headers
text/plain 1.1k
Father Chrysostomos wrote: Show quoted text
>use warnings; >{ package # hide from PAUSE > Hash::Util; use warnings::register } >no warnings qw 'once Hash::Util';
That's nasty. warnings::register is a shortcut for the common case of packages registering their own category; it's just obfuscatory to go through it to register an unrelated package's category. Show quoted text
>use warnings; >BEGIN { warnings::register_categories "Hash::Util" } >no warnings qw 'once Hash::Util';
This is what I envisioned, and I think it's the pattern to favour. It's nice and clear, with the registration explicit and distinct from the bitset toggling. Show quoted text
>use warnings; >no warnings 'once' , REGISTER => "Hash::Util";
Strikes me as confusing. What does it do to the Hash::Util category, exactly? Register it, yes, but also operate on its lexical enablement? More a problem with "use warnings REGISTER => ...", but it's unclear in any case. Also, the FATAL/NONFATAL directives are confusing enough, and this would introduce combinations of the directives. Registering someone else's warning category is an unusual requirement. It doesn't need to be especially succinct. -zefram
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.6k
On Mon, 20 Nov 2017 01:56:20 -0800, zefram@fysh.org wrote: Show quoted text
> Father Chrysostomos wrote:
> >use warnings; > >{ package # hide from PAUSE > > Hash::Util; use warnings::register } > >no warnings qw 'once Hash::Util';
> > That's nasty. warnings::register is a shortcut for the common case of > packages registering their own category; it's just obfuscatory to go > through it to register an unrelated package's category. >
> >use warnings; > >BEGIN { warnings::register_categories "Hash::Util" } > >no warnings qw 'once Hash::Util';
> > This is what I envisioned, and I think it's the pattern to favour. > It's nice and clear, with the registration explicit and distinct from > the bitset toggling. >
> >use warnings; > >no warnings 'once' , REGISTER => "Hash::Util";
> > Strikes me as confusing. What does it do to the Hash::Util category, > exactly? Register it, yes, but also operate on its lexical enablement? > More a problem with "use warnings REGISTER => ...", but it's unclear > in any case. Also, the FATAL/NONFATAL directives are confusing enough, > and this would introduce combinations of the directives.
I think you are right. It is confusing. Show quoted text
> Registering someone else's warning category is an unusual requirement. > It doesn't need to be especially succinct.
It’s not that unusual if you consider that it was because of overload.pm that I filed this ticket to begin with. At the very least, can we make warnings.pm register the overload category, or make overload a core category? I want to avoid this, which is not very maintainable: use warnings; use overload (); no warnings 'overload'; use overload ....; -- Father Chrysostomos
From: Zefram <zefram [...] fysh.org>
Subject: Re: [perl #108778] no warnings "module name"
Date: Wed, 13 Dec 2017 20:32:45 +0000
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 231b
Father Chrysostomos via RT wrote: Show quoted text
>At the very least, can we make warnings.pm register the overload >category, or make overload a core category?
If we do that for overload, why not for others? Where do we draw the line? -zefram
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 779b
On Wed, 13 Dec 2017 12:32:58 -0800, zefram@fysh.org wrote: Show quoted text
> Father Chrysostomos via RT wrote:
> >At the very least, can we make warnings.pm register the overload > >category, or make overload a core category?
> > If we do that for overload, why not for others? Where do we draw > the line?
overload.pm, like strict and warnings, is a core feature. The functionality these modules provide is not actually implemented in the modules themselves, but is part of perl. That overload.pm registers its own warnings category and uses warnings::warnif is just an implementation detail. Its warnings are even listed in perldiag under the ‘overload’ category. Hence, I think it is sufficiently part of the language itself, and not just another module. -- Father Chrysostomos


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org