One other bit of randomness that I noticed: ecpg's parse.pl has
this undocumented bit of logic:
if ($a eq 'IDENT' && $prior eq '%nonassoc')
{
# add more tokens to the list
$str = $str . "\n%nonassoc CSTRING";
Andres Freund writes:
> On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
>> 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
On 2024-04-18 23:11:52 -0400, Tom Lane wrote:
> Andres Freund 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
Andres Freund 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
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