Fix -Wshadow=local warnings

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Fix -Wshadow=local warnings
Date: 2026-09-01 14:58:44
Message-ID: 84b6f128-91f5-480e-8a9e-7d0e8f538cea@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I bumped into some variable shadowings that to my slight surprise the
current warning option -Wshadow=compatible-local does not catch. For
example

const char *p;
char *p;

or

bool skipped;
int64 skipped;

These are not "compatible" in the technical C language sense, but they
are mutually assignable, so IMO just as confusing and fragile.

Also, there are things like

EState *estate;
ExprState *estate;

which are not mutually assignable, but almost as dangerous given the
propensity to cast node types around.

These can be caught if we dial up the warning one notch to
-Wshadow=local. This then flags all shadowing of a local variable by
another local variable. I have fixed all the warnings in the attached
patch. I think everything this catches is obviously bad, so this seems
well worth fixing. (And if we buy into the idea of
-Wshadow=compatible-local, then this is obviously better and more complete.)

So the first patch fixes all the warnings, but doesn't turn up the
compiler flag yet. There is a hiccup with the LLVM headers, because
they themselves trigger these warnings. So the second patch provides a
workaround to silence warnings from those headers. It's a bit different
from what we have done before, but I think it works better for this
case. Alternative ideas welcome. In the third patch, the warning
option is then changed.

Attachment Content-Type Size
0001-Fix-Wshadow-local-warnings.patch text/plain 88.1 KB
0002-Use-isystem-for-LLVM-include-directories.patch text/plain 3.3 KB
0003-Use-warning-option-Wshadow-local.patch text/plain 5.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2026-09-01 15:20:01 Re: PGQ catalog representation and pg_dump support
Previous Message Tom Lane 2026-09-01 14:48:39 Re: foreign_key test is sensitive to the OID counter