Re: ECPG cleanup and fix for clang compile-time problem - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ECPG cleanup and fix for clang compile-time problem
Date
Msg-id 20240419030346.kmhmsvf2dofgeazn@awork3.anarazel.de
Whole thread Raw
In response to ECPG cleanup and fix for clang compile-time problem  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: ECPG cleanup and fix for clang compile-time problem
List 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@gmx.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.paquier@gmail.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



pgsql-hackers by date:

Previous
From: "Hayato Kuroda (Fujitsu)"
Date:
Subject: RE: Disallow changing slot's failover option in transaction block
Next
From: Tom Lane
Date:
Subject: Re: ECPG cleanup and fix for clang compile-time problem