On Tue, Sep 20, 2022 at 7:20 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > * With %pure-parser, Bison makes the "yynerrs" variable local > instead of static, and then if you don't use it clang notices > that it's set but never read. There doesn't seem to be a way > to persuade Bison not to emit the variable at all, so here I've > just added "(void) yynerrs;" to the topmost production of each > affected grammar. If anyone has a nicer idea, let's hear it.
+1. FTR they know about this: https://www.mail-archive.com/bison-patches@gnu.org/msg07836.html https://github.com/akimd/bison/commit/a166d5450e3f47587b98f6005f9f5627dbe21a5b ... but that YY_ATTRIBUTE_UNUSED hasn't landed in my systems' /usr[/local]/share/bison/skeletons/yacc.c yet and it seems harmless and also legitimate to reference yynerrs from an action. > * xlog.c's AdvanceXLInsertBuffer has a local variable "npages" > that is only read in the "#ifdef WAL_DEBUG" stanza at the > bottom. Here I've done the rather ugly and brute-force thing > of wrapping all the variable's references in "#ifdef WAL_DEBUG". > (I tried marking it PG_USED_FOR_ASSERTS_ONLY, but oddly that > did not silence the warning.) I kind of wonder how useful this > function's WAL_DEBUG output is --- maybe just dropping that > altogether would be better? No opinion on the value of the message, but maybe pg_attribute_unused() would be better? > * array_typanalyze.c's compute_array_stats counts the number > of null arrays in the column, but then does nothing with the > result. AFAICS this is redundant with what std_compute_stats > will do, so I just removed the variable. +1