Proposed mid-cycle update of typedefs.list

Hi,

On 2025-12-14 14:57:48 -0500, Tom Lane wrote:

I happened to notice that the buildfarm's current typedefs list
adds quite a few names that were not previously being captured,
for example

@@ -48,10 +48,15 @@ AggPath
AggSplit
AggState
AggStatePerAgg
+AggStatePerAggData
AggStatePerGroup
+AggStatePerGroupData
AggStatePerHash
+AggStatePerHashData
AggStatePerPhase
+AggStatePerPhaseData
AggStatePerTrans
+AggStatePerTransData
AggStrategy
AggTransInfo
Aggref

This is great, because it means that the declarations of these
structs need not look funny anymore. But I am not quite sure why
this happened. It's not a BF tooling change as I first thought,
because multiple animals are reporting these names and the
same animals are not capturing these names on the back branches.
The best theory I can come up with is that 1b105f947 et al
used these names in palloc0_array and similar calls, and that
somehow looks like a capturable typedef reference ... but how?

That's indeed curious. I wonder if it's because the return type is cast
differently:

Before:
peraggs = (AggStatePerAgg) palloc0(sizeof(AggStatePerAggData) * numaggs);
after
peraggs = palloc0_array(AggStatePerAggData, numaggs);
where palloc_array() will transform that to

peraggs = (AggStatePerAggData*) palloc(sizeof(AggStatePerAggData) * numaggs);

note that the return type is cast to AggStatePerAggData instead of
AggStatePerAgg. Other than the sizeof() there previously were no references
to AggStatePerAggData. But I guess the intermediary of type
AggStatePerAggData* now leads to it being in the debug info.

LGTM.

One change I did not apply is that the buildfarm's list omits pgoff_t,
although we certainly still use that. This is evidently because
pgoff_t is defined as a macro not a typedef name. I guess we've been
manually preserving that name in the list, but it seems like we should
change "#define pgoff_t off_t" to "typedef off_t pgoff_t;" to avoid
that manual hack. I've not done that here, though.

Sounds like a good idea to me.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:

On 2025-12-14 14:57:48 -0500, Tom Lane wrote:

The best theory I can come up with is that 1b105f947 et al
used these names in palloc0_array and similar calls, and that
somehow looks like a capturable typedef reference ... but how?

That's indeed curious. I wonder if it's because the return type is cast
differently:

Guess it must be. I had thought that our tooling captures types
that are used to declare variables or fields of struct variables,
but evidently that's not the whole story. One thing we do know
for sure is that "sizeof(footype)" does not create a capturable
reference to footype. But maybe references within casts do?

One change I did not apply is that the buildfarm's list omits pgoff_t,
although we certainly still use that. This is evidently because
pgoff_t is defined as a macro not a typedef name. I guess we've been
manually preserving that name in the list, but it seems like we should
change "#define pgoff_t off_t" to "typedef off_t pgoff_t;" to avoid
that manual hack. I've not done that here, though.

Sounds like a good idea to me.

I'll go deal with these things shortly.

regards, tom lane

On Sun, Dec 14, 2025 at 04:38:59PM -0500, Tom Lane wrote:

I'll go deal with these things shortly.

Thanks for cleaning up all that!
--
Michael