[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Unhelpful noisy diagnostics from newer Bison.

From: Kaz Kylheku
Subject: Unhelpful noisy diagnostics from newer Bison.
Date: Fri, 10 Jan 2020 18:11:05 -0800
User-agent: Roundcube Webmail/0.9.2


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]


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]