On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
> Andres Freund <and...@anarazel.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.
At least locally the coverage seems to make sense too, both for the main
grammar and for ecpg's.
> > 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.
Hm. Here it mostly looks reasonable, except that at least things seem off by
1. And sure enough, if I look at pgc.l it has code like
case 2:
YY_RULE_SETUP
#line 465 "/home/andres/src/postgresql/src/interfaces/ecpg/preproc/pgc.l"
{
token_start = yytext;
state_before_str_start = YYSTATE;
However line 465 is actually the "token_start" line.
Further down this seems to get worse, by "<<EOF>>" it's off by 4 lines.
$ apt policy flex
flex:
Installed: 2.6.4-8.2+b2
Candidate: 2.6.4-8.2+b2
Version table:
*** 2.6.4-8.2+b2 500
500 http://mirrors.ocf.berkeley.edu/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
Greetings,
Andres Freund
