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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
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:11:52
Message-ID: 2039829.1713496312@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2024-04-18 22:18:34 -0400, Tom Lane wrote:
>> (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.:

Yeah, I'd just noticed that --- I had it in my head that we'd put
LCOV_EXCL_START/STOP into bison files too, but nope they are only
in flex files. That's good for this specific problem, because the
code I'm worried about is all in the bison file.

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

I was just looking locally at what I got by removing that, and sadly
I don't think I believe it: there are a lot of places where it claims
we hit lines we don't, and vice versa. That might be partially
blamable on old tools on my RHEL8 workstation, but it sure seems
that flex output confuses lcov to some extent.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2024-04-19 03:40:22 Re: ECPG cleanup and fix for clang compile-time problem
Previous Message Andres Freund 2024-04-19 03:03:46 Re: ECPG cleanup and fix for clang compile-time problem