Re: ECPG cleanup and fix for clang compile-time problem

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Subject: Re: ECPG cleanup and fix for clang compile-time problem
Date: 2024-04-19 03:03:46
Message-ID: 20240419030346.kmhmsvf2dofgeazn@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
> Here is a patch series that aims to clean up ecpg's preprocessor
> code a little and fix the compile time problems we're seeing with
> late-model clang [1]. I guess whether it's a cleanup is in the eye of
> the beholder, but it definitely succeeds at fixing compile time: for
> me, the time needed to compile preproc.o with clang 16 drops from
> 104 seconds to less than 1 second. It might be a little faster at
> processing input too, though that wasn't the primary goal.

Nice! I'll look at this more later.

For now I just wanted to point one minor detail:

> (If our code coverage tools worked on bison/flex stuff,
> maybe this'd be less scary ... but they don't.)

For bison coverage seems to work, see e.g.:

https://coverage.postgresql.org/src/interfaces/ecpg/preproc/preproc.y.gcov.html#10638

I think the only reason it doesn't work for flex is that we have
/* LCOV_EXCL_START */
/* LCOV_EXCL_STOP */

around the scanner "body". Without that I get reasonable-looking, albeit not
very comforting, coverage for pgc.l as well.

|Lines |Functions|Branches
Filename |Rate Num|Rate Num|Rate Num
src/interfaces/ecpg/preproc/pgc.l |65.9% 748|87.5% 8| - 0
src/interfaces/ecpg/preproc/preproc.y |29.9% 4964|66.7% 15| - 0

This has been introduced by

commit 421167362242ce1fb46d6d720798787e7cd65aad
Author: Peter Eisentraut <peter_e(at)gmx(dot)net>
Date: 2017-08-10 23:33:47 -0400

Exclude flex-generated code from coverage testing

Flex generates a lot of functions that are not actually used. In order
to avoid coverage figures being ruined by that, mark up the part of the
.l files where the generated code appears by lcov exclusion markers.
That way, lcov will typically only reported on coverage for the .l file,
which is under our control, but not for the .c file.

Reviewed-by: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>

but I don't think it's working as intended, as it's also preventing coverage
for the actual scanner definition.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-04-19 03:11:52 Re: ECPG cleanup and fix for clang compile-time problem
Previous Message Hayato Kuroda (Fujitsu) 2024-04-19 02:54:17 RE: Disallow changing slot's failover option in transaction block