Thread: plperl tests fail with latest Perl 5.36
Apparently 5.36 rejiggers warning classifications in a way that breaks one of our test cases. Perhaps we should switch it to some other warning-triggering condition. regards, tom lane ------- Forwarded Message Date: Wed, 01 Jun 2022 14:08:46 +0000 From: bugzilla@redhat.com To: tgl@sss.pgh.pa.us Subject: [Bug 2092426] New: postgresql-14.3-1.fc37: FTBFS with Perl 5.36 https://bugzilla.redhat.com/show_bug.cgi?id=2092426 Bug ID: 2092426 Summary: postgresql-14.3-1.fc37: FTBFS with Perl 5.36 Product: Fedora Version: rawhide URL: https://koji.fedoraproject.org/koji/buildinfo?buildID= 1974481 Status: NEW Component: postgresql Assignee: fjanus@redhat.com Reporter: jplesnik@redhat.com QA Contact: extras-qa@fedoraproject.org CC: anon.amish@gmail.com, devrim@gunduz.org, fjanus@redhat.com, hhorak@redhat.com, jmlich83@gmail.com, mkulik@redhat.com, panovotn@redhat.com, pkubat@redhat.com, praiskup@redhat.com, tgl@sss.pgh.pa.us Target Milestone: --- Classification: Fedora I am working on adding Perl 5.36 to Fedora Rawhide/37 (not done yet). The rebuild of postgresql failed with this version in side tag f37-perl: === make failure: src/pl/plperl/regression.diffs === diff -U3 /builddir/build/BUILD/postgresql-14.3/src/pl/plperl/expected/plperl.out /builddir/build/BUILD/postgresql-14.3/src/pl/plperl/results/plperl.out --- /builddir/build/BUILD/postgresql-14.3/src/pl/plperl/expected/plperl.out 2022-05-09 21:14:45.000000000 +0000 +++ /builddir/build/BUILD/postgresql-14.3/src/pl/plperl/results/plperl.out 2022-06-01 11:23:50.925042793 +0000 @@ -726,8 +726,6 @@ -- check that we can "use warnings" (in this case to turn a warn into an error) -- yields "ERROR: Useless use of sort in scalar context." DO $do$ use warnings FATAL => qw(void) ; my @y; my $x = sort @y; 1; $do$ LANGUAGE plperl; -ERROR: Useless use of sort in scalar context at line 1. -CONTEXT: PL/Perl anonymous code block -- make sure functions marked as VOID without an explicit return work CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$ $_SHARED{myquote} = sub { The reason of the failure is a change to existing diagnostics[1]: "Useless use of sort in scalar context is now in the new scalar category. When sort is used in scalar context, it provokes a warning that doing this is not useful. This warning used to be in the void category. A new category for warnings about scalar context has now been added, called scalar." Solution is replacing use warnings FATAL => qw(void) by use warnings FATAL => qw(scalar) for this case. [1] https://metacpan.org/dist/perl/view/pod/perldelta.pod#Changes-to-Existing-Diagnostics -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2092426 ------- End of Forwarded Message
Tom Lane <tgl@sss.pgh.pa.us> writes: > Apparently 5.36 rejiggers warning classifications in a way that breaks > one of our test cases. Perhaps we should switch it to some other > warning-triggering condition. The simplest thing is to actually use sort in void context, i.e. removing the `my $x = ` part from the test, see the attached. Tested on 5.36.0 and 5.8.9. - ilmari From e8ab5acf49c9e78a523beb01b37bcd506665f254 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Dagfinn=20Ilmari=20Manns=C3=A5ker?= <ilmari@ilmari.org> Date: Wed, 1 Jun 2022 16:07:48 +0100 Subject: [PATCH] Fix plperl test for change of warning category in perl 5.36 The warning about using in scalar context is now in the 'scalar' category, not 'void'. Actually use sort in void context to keep the warning in the same category across perl versions. --- src/pl/plperl/expected/plperl.out | 4 ++-- src/pl/plperl/sql/plperl.sql | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/pl/plperl/expected/plperl.out b/src/pl/plperl/expected/plperl.out index d8a1ff5dd8..aa02bcd5bb 100644 --- a/src/pl/plperl/expected/plperl.out +++ b/src/pl/plperl/expected/plperl.out @@ -725,8 +725,8 @@ ERROR: Can't use string ("foo") as a SCALAR ref while "strict refs" in use at l CONTEXT: PL/Perl anonymous code block -- check that we can "use warnings" (in this case to turn a warn into an error) -- yields "ERROR: Useless use of sort in scalar context." -DO $do$ use warnings FATAL => qw(void) ; my @y; my $x = sort @y; 1; $do$ LANGUAGE plperl; -ERROR: Useless use of sort in scalar context at line 1. +DO $do$ use warnings FATAL => qw(void) ; my @y; sort @y; 1; $do$ LANGUAGE plperl; +ERROR: Useless use of sort in void context at line 1. CONTEXT: PL/Perl anonymous code block -- make sure functions marked as VOID without an explicit return work CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$ diff --git a/src/pl/plperl/sql/plperl.sql b/src/pl/plperl/sql/plperl.sql index b0d950b230..ab222366cd 100644 --- a/src/pl/plperl/sql/plperl.sql +++ b/src/pl/plperl/sql/plperl.sql @@ -470,7 +470,7 @@ DO $do$ use strict; my $name = "foo"; my $ref = $$name; $do$ LANGUAGE plperl; -- check that we can "use warnings" (in this case to turn a warn into an error) -- yields "ERROR: Useless use of sort in scalar context." -DO $do$ use warnings FATAL => qw(void) ; my @y; my $x = sort @y; 1; $do$ LANGUAGE plperl; +DO $do$ use warnings FATAL => qw(void) ; my @y; sort @y; 1; $do$ LANGUAGE plperl; -- make sure functions marked as VOID without an explicit return work CREATE OR REPLACE FUNCTION myfuncs() RETURNS void AS $$ -- 2.30.2
=?utf-8?Q?Dagfinn_Ilmari_Manns=C3=A5ker?= <ilmari@ilmari.org> writes: > Tom Lane <tgl@sss.pgh.pa.us> writes: >> Apparently 5.36 rejiggers warning classifications in a way that breaks >> one of our test cases. Perhaps we should switch it to some other >> warning-triggering condition. > The simplest thing is to actually use sort in void context, > i.e. removing the `my $x = ` part from the test, see the attached. Looks reasonable to me, but I'm hardly a Perl monk. Anybody have a different opinion? regards, tom lane
On Wed, Jun 1, 2022 at 11:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Looks reasonable to me, but I'm hardly a Perl monk. Anybody have > a different opinion? Well, it falsifies the immediately preceding comment, but I think it's fine otherwise. -- Robert Haas EDB: http://www.enterprisedb.com
Robert Haas <robertmhaas@gmail.com> writes: > On Wed, Jun 1, 2022 at 11:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Looks reasonable to me, but I'm hardly a Perl monk. Anybody have >> a different opinion? > Well, it falsifies the immediately preceding comment, but I think it's > fine otherwise. Duh, right, will fix. This seems appropriate to back-patch as far as 9.2, since AFAIK there's not currently anything that breaks plperl in the out-of-support branches. regards, tom lane