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
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 |