bug-bison
[Top][All Lists]
Advanced

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

Re: Please revert the %pure-parser deprecation message


From: Akim Demaille
Subject: Re: Please revert the %pure-parser deprecation message
Date: Sun, 30 Jun 2019 17:16:24 +0200

Hi Peter,

> Le 30 juin 2019 à 14:19, Peter Wu <address@hidden> a écrit :
> 
> Hi,
> 
> Starting with Bison 3.4, use of '%pure-parser' started emitting
> deprecation warnings, recommending '%define api.pure' instead. The
> latter however is a non-standard directive which is not implemented by
> Berkeley YACC.

Actually, %pure-parser is a non standard directive, it's a Bison
extension (http://pubs.opengroup.org/onlinepubs/009695399/utilities/yacc.html).

And it is broken, in different ways, people should
stop using it.  So it's not a matter of style, it's a way to
deprecate, and eventually to eliminate, a badly designed feature.

To be clear, '%define api.pure' is also deprecated, use
'%define api.pure full'.  See the NEWS file about Bison 2.7 for details:

** New value for %define variable: api.pure full

  The %define variable api.pure requests a pure (reentrant) parser. However,
  for historical reasons, using it in a location-tracking Yacc parser
  resulted in a yyerror function that did not take a location as a
  parameter. With this new value, the user may request a better pure parser,
  where yyerror does take a location as a parameter (in location-tracking
  parsers).

  The use of "%define api.pure true" is deprecated in favor of this new
  "%define api.pure full".

> Berkeley YACC does implement %pure-parser instead:
> https://invisible-island.net/byacc/manpage/yacc.html

It's nice to see that Bison extensions get support from other tools!
But then they should also follow our deprecations.

> Correct me if I am wrong, but it appears that the change to '%define
> api.pure' is purely a stylistic one. In our project, use of '%define
> api.pure [full]' makes no difference in the generated code.

You probably don't use locations then.  Compare

> %locations
> %pure-parser
> %%
> exp:

versus

> %locations
> %define api.pure "full"
> %%
> exp:

It gives

> $ gdiff -U0 pure.c define.c
> --- pure.c      2019-06-30 17:11:14.953682048 +0200
> +++ define.c    2019-06-30 17:11:28.357559451 +0200
> @@ -57 +57 @@
> -#define YYPURE 1
> +#define YYPURE 2
> @@ -534 +534 @@
> -        yyerror (YY_("syntax error: cannot back up")); \
> +        yyerror (&yylloc, YY_("syntax error: cannot back up")); \
> @@ -1292 +1292 @@
> -#line 1293 "pure.c"
> +#line 1293 "define.c"
> @@ -1353 +1353 @@
> -      yyerror (YY_("syntax error"));
> +      yyerror (&yylloc, YY_("syntax error"));
> @@ -1380 +1380 @@
> -        yyerror (yymsgp);
> +        yyerror (&yylloc, yymsgp);
> @@ -1502 +1502 @@
> -  yyerror (YY_("memory exhausted"));
> +  yyerror (&yylloc, YY_("memory exhausted"));


> Would it be possible to revert the diagnostic message? -Wno-deprecated
> (added in Bison 2.7) does hide it, but that requires extra custom code.

We keep backward compatibility for many features, which hinders the
maintainability of Bison, requires tests and documentation.
Eventually, deprecated features will be removed (in a distant future),
but we can't do that without warning our users.  That's the whole point
of -Wdeprecated.


Cheers!


reply via email to

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