Обсуждение: 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