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