warnings::register regressions introduced in 5.10 #9631
Comments
From @ribasushiCreated by rabbit@rabbit.usAfter upgrading to 5.10 warnings::register related warning suppression It passes under 5.8 but breaks in 4 places under 5.10: Failures 5 & 6Let's have Module S which inherits from module C. In module C we have: use warnings::register; .... sub work { in module S we have: sub start_work { Now if a user invokes S->start_work under 5.8 there will be no warning Failure 12Same as above, but class S is generated on the fly via a string eval Failure 15Same as 12, but instead of no warnings 'C', even an unqualified Perl Info |
From @ribasushiI am extending this bug with one more test case which now fails both on Class M is a Class::C3::Componentised. It loads two components D and W sub component_method { shift->next::method (@_); } The one in W has a warning statement (with warnings::register called in Then this still generates a warning both under 5.8 and 5.10: Full test suite (19 points) attached. On Tue Jan 20 02:10:31 2009, rabbit@rabbit.us wrote:
PATH=/home/rabbit/devel/utils:/home/rabbit/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
|
|
The RT System itself - Status changed from 'new' to 'open' |
From p5p@spam.wizbit.beOn Tue Jan 20 02:10:31 2009, rabbit@rabbit.us wrote:
Thanks for the bug report. (Your test script seems to require Class::C3) Kind regards, Bram |
From @ribasushiOn Sat Feb 14 10:35:06 2009, animator wrote:
The file uploaded with the initial bug report[1] contains 16 tests which [1] http://rt.perl.org/rt3/Ticket/Attachment/522408/246780 |
From @ribasushiBram via RT wrote:
The file uploaded with the initial bug report[1] contains 16 tests which are [1] http://rt.perl.org/rt3/Ticket/Attachment/522408/246780/5.10_lexwarn_register.tar.bz2 |
From p5p@spam.wizbit.be
Test case: #!/usr/bin/perl -l { sub p1 { { use strict; sub p2 { use warnings; $ perl-5.8.9 rt-62522-1.pl $ perl-5.10.0 rt-62522-1.pl The reason why the output changed is because of: The summary of that ticket: When Carp::carp/Carp::cloak/Carp:* is used then the output can be Test case: (Difference from the previous test case: removed "no warnings #!/usr/bin/perl -l { sub p1 { { use strict; use warnings; $ perl-5.8.9 rt-62522-2.pl This warning is confusing in the sense that adding no warnings #!/usr/bin/perl -l { sub p1 { { use strict; sub p2 { use warnings; $ perl589 rt-62522-2.pl The behaviour of 5.10 makes sense but so does the behaviour of 5.8... The result of this change is that there is no way to disable a warning Perhaps a better solution is to only return true in warnings::enabled if Any thoughts? Kind regards, Bram |
From p5p@spam.wizbit.beOn Tue Jan 20 02:10:31 2009, rabbit@rabbit.us wrote:
(I'm not sure what the best place for the test code is but in the end I Assume the following test code: #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; my $obj = RT62522::Main->new(); __END__ $ perl-5.8.8 rt-62522.pl $ perl-5.10.0 rt-62522.pl One can very easy conclude from this that disabling the warning can be #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; my $obj = RT62522::Main->new(); __END__ Running it: $ perl-5.8.8 rt-62522.pl $ perl-5.10.0 rt-62522.pl This was the (intended) Change 21167 So, how does one disable the warning on perl-5.8.8? By adding 'no #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; my $obj = RT62522::Main->new(); $ perl-5.8.8 rt-62522.pl $ perl-5.10.0 rt-62522.pl My first idea will silence the warning when: Now going one step further: What if another call/more inherithance is involved? Example: #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; sub some_func3 { { use strict; my $obj = RT62522::Sub->new(); With Idea 1 it is possible to disable the warning in package main and But should you also be able to disable it in the package RT62522::Sub? The downside: it is impossible to explicetly enable a warning; you can All this leaves one important question unanswered/untouched... and this Adding use warnings FATAL => 'all' in RT62522::Main: #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; my $obj = RT62522::Main->new(); $ perl-5.8.8 rt-62522.pl $ perl-5.10.0 rt-62522.pl Adding use warnings FATAL => 'all' in main: #!/usr/bin/perl -l { { use strict; sub new { { use strict; sub some_func2 { { use strict; my $obj = RT62522::Main->new(); $ perl-5.8.8 rt-62522.pl $ perl-5.10.0 rt-62522.pl Where should the FATAL warning be enabled? All that stops me from writing a patch for this is feedback on fatal Best regards, Bram |
From p5p@perl.wizbit.beTo summarise the ticket: The behaviour in 5.10.x favors the person using the module; Assume to following code: - main calls Foo::Bar::baz() On 5.8.x: On 5.10.x: But: sometimes we want the 5.8.x behaviour and sometimes we want the The biggest problem with altering this behaviour is backwards-compatibility: This in itself is a minor issue (IMHO). Assume to following code: - main calls Foo::Bar::baz() On 5.8.x: On 5.10.x: Possible solutions: 1) FATAL warning: die when Downsides: 2) FATAL warning: die when Downsides: 3) FATAL warning: die when: Downsides: 4) ??? After the backwards-compatibilty question/problem is solved then we Best regards, Bram |
From @obraOn Tue 12.Jan'10 at 21:12:37 +0100, Bram wrote:
My inclination is that when we've broken back-compat in a shipped At this point, I'd count the 5.10.0 regression as the "new" default It feels weird to me to design library code that uses fatal warnings in -Jesse |
From @obraBram, What would you like to see happen on this before 5.12.0? -Jesse On Mon Jan 18 10:28:42 2010, jesse wrote:
|
From p5p@perl.wizbit.beJesse, As said yesterday on irc: I'm ok with shipping as is. The 5.10.x behaviour has limited uses cases (IMHO) but so did the Maybe the change in behaviour should be added in perldelta? (Is there Best regards, Bram Citeren Jesse via RT <perlbug-followup@perl.org>:
|
From @obraOn Tue 9.Feb'10 at 19:53:38 +0100, Bram wrote:
Ah, fantastic. I missed that.
We can certainly create one. (And amend the perl5100delta.pod at the Thanks! -Jesse |
|
@obra - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#62522 (status was 'resolved')
Searchable as RT62522$
The text was updated successfully, but these errors were encountered: