Unhelpful noisy diagnostics from newer Bison.

[Kaz Kylheku]

Hi,

Please clean up the following:

$ make
YACC parser.y -> y.tab.c
parser.y:106.1-12: warning: POSIX Yacc does not support %pure-parser 
[-Wyacc]
  106 | %pure-parser
      | ^~~~~~~~~~~~
parser.y:106.1-12: warning: deprecated directive, use ‘%define api.pure’ 
[-Wdeprecated]
  106 | %pure-parser
      | ^~~~~~~~~~~~
parser.y: warning: fix-its can be applied.  Rerun with option 
'--update'. [-Wother]


Notes:

1. Please don't warn about conforming extensions whose presence in
   the file is obviously deliberate. Consider how "gcc -ansi"
   accepts conforming extensions:

   # cat > test.c
   int main(void)
   {
     int a = ({1; 2; 3;});
     return 0;
   }
   # gcc -Wall -ansi test.c
   test.c: In function 'main':
   test.c:3:13: warning: statement with no effect [-Wunused-value]
      3 |   int a = ({1; 2; 3;});
        |             ^
   test.c:3:16: warning: statement with no effect [-Wunused-value]
      3 |   int a = ({1; 2; 3;});
        |                ^
   test.c:3:7: warning: unused variable 'a' [-Wunused-variable]
      3 |   int a = ({1; 2; 3;});
        |       ^

   See? Nothing about ({...}) not being ANSI C! It's a syntax error in 
ANSI C. We can get
   the diagnostic with -pedantic:

   # gcc -Wall -ansi -pedantic test.c
   test.c: In function 'main':
   test.c:3:11: warning: ISO C forbids braced-groups within expressions 
[-Wpedantic ]
   ...

   Please do like GCC and add a --pedantic option to Bison for this sort 
of thing.

   Those who care that their file is POSIX-conforming can use 
--pedantic.

   Can you imagine if GNU cp from Coreutils complained every time we do 
"cp -a from to"
   that -a is not a POSIX option?

   Speaking of commands, "bison --yacc" is not a command described in 
POSIX anyway!

2. Consider that other implementations accept %pure-parser.  My above 
grammar file
   works with Berkeley Yacc, which recognizes %pure-parser. Is the 
deprecation
   of this option being coordinated with Byacc?

   Please, can't we just keep working stuff working, without 
diagnostics?

   What is wrong with silently continuing to recognize %pure-parser 
going forward?

   It's not something dangerous, like the C gets function; it's just a 
way of
   spelling the magic incantation to get a pure parser.

3. What are fix-its? Are they my fault, and why should I care? Please 
don't ask me
   to add strange options to the invocation of the parser generator that 
other
   versions and other implementations don't recognize. If "fix its" can 
be applied,
   and are good, then apply them. It looks like some internal issue 
within the
   skeleton.

This sort of stuff makes work for me. Why? Because I have to go into my 
configure
script, and add detection for this stuff. I cannot pass -Wno-deprecated 
or
--update to the generator unless it's Bison, and in a range of versions 
which
understands those options.  So I will end up creating a minimal test 
program,
running the parser genenrator on it and grepping the output to see 
whether these
errors occur, and then adding the right options to YACC_FLAGS.
I cannot just change to %define api.pure. It's not truly deprecated. Try 
again
in 20, 30 years.

If I don't take these steps, then the build of my program has ugly 
diagnostics
in it.

I don't want to spend my time this way; please make all new bells and 
whistles
OPT-IN, so that code which compiled without fluffy diagnonstics before 
continues to
compile without fluffy diagnostics.

Save the unconditional new diagnostics for situations that are genuine 
problems
in the user's code. If a new opt-out diagnostic actually indicates a 
bug, I will
be more than grateful.

In other words, assume that people treat diagnostics seriously and give 
us
only serious new diagnostics as opt-outs. Also assume that people read
documentation and will find useful new opt-in diagnostics on their own.
Sure, that will probably take longer; and 20+ years later, some projects
still won't be using those diagnostics. Forcing it on people to get them 
to
notice is not the way, though.

Thanks!