Tom Lane <t...@sss.pgh.pa.us> writes:
> I wrote:
>> Peter Eisentraut <pete...@gmx.net> writes:
>>> Clean up Perl code according to perlcritic
>
>> This seems to have broken the regression tests (specifically, dblink)
>> on at least some of the Windows buildfarm critters.
>
> I'm hardly a Perl expert, but it looks to me like the culprit is this
> hunk in vcregress.pl:
>
> @@ -521,8 +521,9 @@ sub fetchRegressOpts
> # an unhandled variable reference. Ignore anything that isn't
> an
> # option starting with "--".
> @opts = grep {
> - s/\Q$(top_builddir)\E/\"$topdir\"/;
> - $_ !~ /\$\(/ && $_ =~ /^--/
> + my $x = $_;
> + $x =~ s/\Q$(top_builddir)\E/\"$topdir\"/;
> + $x !~ /\$\(/ && $x =~ /^--/
> } split(/\s+/, $1);
> }
> if ($m =~ /^\s*ENCODING\s*=\s*(\S+)/m)
>
> The first line in that block is actually intending to modify the value
> it's inspecting, and perlcritic's "improved" version carefully removes
> the side-effect.
>
> No doubt there are cleaner ways to do that (the comments in "man perlfunc"
> about this coding technique are not positive), but this way is not
> cleaner, it is broken.
I suggest splitting the substitution and filtering part into separate
map and grep calls, for clarity. The substituion is crying out for the
/r regex modifier to avoid the local variable, but that's only available
since perl 5.14.
diff --git a/src/tools/msvc/vcregress.pl b/src/tools/msvc/vcregress.pl
index d9367f8..cf93a60 100644
--- a/src/tools/msvc/vcregress.pl
+++ b/src/tools/msvc/vcregress.pl
@@ -520,11 +520,9 @@ sub fetchRegressOpts
# Substitute known Makefile variables, then ignore options that
retain
# an unhandled variable reference. Ignore anything that isn't
an
# option starting with "--".
- @opts = grep {
- my $x = $_;
- $x =~ s/\Q$(top_builddir)\E/\"$topdir\"/;
- $x !~ /\$\(/ && $x =~ /^--/
- } split(/\s+/, $1);
+ @opts = grep { !/\$\(/ && /^--/ }
+ map { (my $x = $_) =~
s/\Q$(top_builddir)\E/\"$topdir\"/; $x;}
+ split(/\s+/, $1);
}
if ($m =~ /^\s*ENCODING\s*=\s*(\S+)/m)
{
- ilmari
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
