Skip to content
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 "module name" #11888

Open
p5pRT opened this issue Jan 22, 2012 · 14 comments
Open

no warnings "module name" #11888

p5pRT opened this issue Jan 22, 2012 · 14 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 22, 2012

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

Searchable as RT108778$

@p5pRT
Copy link
Author

p5pRT commented Jan 22, 2012

From @cpansprout

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​: bdd2b37
  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

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2012

From @cpansprout

On Sun Jan 22 12​:52​:17 2012, sprout wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2012

From [Unknown Contact. See original ticket]

On Sun Jan 22 12​:52​:17 2012, sprout wrote​:

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

@p5pRT
Copy link
Author

p5pRT commented Jan 23, 2012

@cpansprout - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2017

From zefram@fysh.org

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.

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.

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

@p5pRT
Copy link
Author

p5pRT commented Nov 15, 2017

From zefram@fysh.org

I wrote​:

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 006c1a1. 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

@p5pRT
Copy link
Author

p5pRT commented Nov 19, 2017

From @cpansprout

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

Do you think it would be reasonable to add a REGISTER directive, similar to FATAL?

use warnings;
no warnings 'once' , REGISTER => "Hash​::Util";

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.

@p5pRT
Copy link
Author

p5pRT commented Nov 19, 2017

From @xsawyerx

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.

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.

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. :)

@p5pRT
Copy link
Author

p5pRT commented Nov 20, 2017

From @cpansprout

On Sun, 19 Nov 2017 12​:47​:25 -0800, xsawyerx@​gmail.com wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Nov 20, 2017

From zefram@fysh.org

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.

Registering someone else's warning category is an unusual requirement.
It doesn't need to be especially succinct.

-zefram

@p5pRT
Copy link
Author

p5pRT commented Nov 21, 2017

From @cpansprout

On Mon, 20 Nov 2017 01​:56​:20 -0800, zefram@​fysh.org wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Nov 21, 2017

From [Unknown Contact. See original ticket]

On Mon, 20 Nov 2017 01​:56​:20 -0800, zefram@​fysh.org wrote​:

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.

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

@p5pRT
Copy link
Author

p5pRT commented Dec 13, 2017

From zefram@fysh.org

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?

-zefram

@p5pRT
Copy link
Author

p5pRT commented Dec 17, 2017

From @cpansprout

On Wed, 13 Dec 2017 12​:32​:58 -0800, zefram@​fysh.org wrote​:

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants