bug-bison
[Top][All Lists]
Advanced

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

Re: Unhelpful noisy diagnostics from newer Bison.


From: Akim Demaille
Subject: Re: Unhelpful noisy diagnostics from newer Bison.
Date: Sat, 11 Jan 2020 07:09:47 +0100

Hi Kaz,

> Le 11 janv. 2020 à 03:11, Kaz Kylheku <address@hidden> a écrit :
> 
> 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]

You passed -Wyacc and get warnings about directives that are Bison
specific.  And you did not pass -Wno-deprecated and get diagnostics
about deprecated directives.

It's unfortunate that we don't see how bison was run, but I bet it
was given -y/--yacc, which triggers, of course, -Wyacc.
You should rather use bison -o y.tab.c if you want to get the yacc-style
file names without asking for Yacc warnings.


> 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?

Hum.  Well, %pure-parser was introduced by Bison.  I think Bison
is entitled to deal with its own directives.  And it has been
deprecated since Bison 2.4, more than ten years ago.  But it seems
people did not pay attention to this, hence the warnings.


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

The current behavior is not the best one for your use case, and I'm
sorry about that.  Yet this is the only way we can tell our users
when they should update their files, and when they depart from
POSIX Yacc.


> 3. What are fix-its?

See the documentation of --update.
https://www.gnu.org/software/bison/manual/html_node/Operation-Modes.html



> 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,

I wouldn't run --update blindly in a Makefile.  That's not the point.

> and in a range of versions which understands those options.

That's not the Autoconf-way.  The right way to do it is:

> 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.

Yes it is.  Its support is not removed, but it's 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;

I fully understand this.  How about providing Autoconf macros in Bison
to factor this effort?



> please make all new bells and whistles
> OPT-IN, so that code which compiled without fluffy diagnostics 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.

-Wdeprecated is not a new diagnostic, it was introduced in Bison 3.0
to isolate deprecation warnings from "other" warnings.

However the case of %pure-parser was indeed added fairly recently.

https://lists.gnu.org/archive/html/bug-bison/2018-12/msg00029.html

> 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.

In this precise case, this is exactly what I want to avoid: having to
maintain for ever obsolete features.  So it is on purpose that -Wdeprecated
is enabled by default.


I have sympathy for your pain, I really do.  I'm not sure what to do
about it though.  If you were using Bison only, you wouldn't have any
problem, it's because you want to be compatible with byacc that you
face these issues.  And byacc implements Bison features, without
telling us, and don't follow our evolutions.

Let me think about it for a while.  Other opinions would be helpful.

Cheers!


reply via email to

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