Re: Make all Perl warnings fatal - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: Make all Perl warnings fatal
Date
Msg-id f724d1d8-1d34-8a47-3dbb-3f35096c83ec@dunslane.net
Whole thread Raw
In response to Re: Make all Perl warnings fatal  (Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>)
List pgsql-hackers


On 2023-08-25 Fr 16:49, Dagfinn Ilmari Mannsåker wrote:
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:

On 2023-Aug-10, Peter Eisentraut wrote:

I wanted to figure put if we can catch these more reliably, in the style of
-Werror.  AFAICT, there is no way to automatically turn all warnings into
fatal errors.  But there is a way to do it per script, by replacing
    use warnings;

by
    use warnings FATAL => 'all';

See attached patch to try it out.
BTW in case we do find that there's some unforeseen problem and we want
to roll back, it would be great to have a way to disable this without
having to edit every single Perl file again later.  However, I didn't
find a way to do it -- I thought about creating a separate PgWarnings.pm
file that would do the "use warnings FATAL => 'all'" dance and which
every other Perl file would use or include; but couldn't make it work.
Maybe some Perl expert knows a good answer to this.
Like most pragmas (all-lower-case module names), `warnings` affects the
currently-compiling lexical scope, so to have a module like PgWarnings
inject it into the module that uses it, you'd call warnings->import in
its import method (which gets called when the `use PgWarnings;``
statement is compiled, e.g.:

package PgWarnings;

sub import {	warnings->import(FATAL => 'all');
}

I wouldn't bother with a whole module just for that, but if we have a
group of pragmas or modules we always want to enable/import and have the
ability to change this set without having to edit all the files, it's
quite common to have a ProjectName::Policy module that does that.  For
example, to exclude warnings that are unsafe, pointless, or impossible
to fatalise (c.f. https://metacpan.org/pod/strictures#CATEGORY-SELECTIONS):

package PostgreSQL::Policy;

sub import {	strict->import;	warnings->import(		FATAL => 'all',		NONFATAL => qw(exec internal malloc recursion),	);	warnings->uniport(qw(once));
}

Now that we require Perl 5.14, we might want to consider enabling its
feature bundle as well, with:
	feature->import(':5.14')

Although the only features of note that adds are:
   - say: the `say` function, like `print` but appends a newline
   - state: `state` variables, like `my` but only initialised the first     time the function they're in is called, and the value persists     between calls (like function-scoped `static` variables in C)
   - unicode_strings: use unicode semantics for characters in the     128-255 range, regardless of internal representation


We'd probably have to modify the perlcritic rules to account for it. See <https://metacpan.org/pod/Perl::Critic::Policy::TestingAndDebugging::RequireUseStrict> and similarly for RequireUseWarnings. In any case, it seems a bit like overkill.


Maybe the BEGIN block of each file can `eval` a new PgWarnings.pm that
emits the "use warnings" line?
That's ugly as sin, and thankfully not necessary.


Agreed.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Ignore 2PC transaction GIDs in query jumbling
Next
From: Ankit Pandey
Date:
Subject: [PoC] Implementation of distinct in Window Aggregates: take two