| Subject: | More flexible handling of warnings. |
The issue which led to this report is that when this module tests code using an INIT block or using third party code which uses an INIT block, it will result in a "Too late to run INIT block" warning. This is due to the test's use of a run-time "require" to load the code.
Turning off fatal warnings via the "fail_on_warning" option alleviates this, but reduces the effectiveness of tests, as all warnings are ignored. Using the "switch" option to turn a specific warning off doesn't help if warnings are turned on in the code which is being compiled, e.g.:
package Foo;
use strict;
use warnings;
our $var;
INIT { $var = 1 }
1;
% perl -M-warnings=void -I. -e 'require q[Foo.pm]'
Too late to run INIT block at Foo.pm line 7.
Fundamentally the issue is that one cannot deterministically change the warnings categories enabled in the included code. In this particular example, the use of "require" to load code using an INIT block illustrates how warnings outside of a developer's control can be generated by correctly working third party code.
One approach to solving this problem would be to embed the heuristics in the "splain" program (see the documentation for the diagnostics pragma) into the compile test. This program parses the messages output by Perl and compares them to the documentation in perldiag. One key element of the latter is that it explicitly specifies the warnings categories for messages associated with warnings.
With this information, the compile tests could identify warnings and filter on them directly.
Is this an approach which is acceptable, and would you consider accepting code to implement this?
Thanks,
Diab