Use %define parse.error verbose instead of YYERROR_VERBOSE

[akimd]

The YYERROR_VERBOSE macro will no longer be supported in Bison 3.6.
It was superseded by the %error-verbose directive in Bison 1.875 (2003-01-01). Bison 2.6 (2012-07-19) clearly announced that support for YYERROR_VERBOSE would be removed. Note that since Bison 3.0 (2013-07-25), %error-verbose is deprecated in favor of %define parse.error verbose.

[carusogabriel]

Do we need to port these changes to https://github.com/php/php-src/blob/master/ext/json/json_parser.y as well?

[akimd]

Hi,
I have put these changes wherever YYERROR_VERBOSE is used, which is not the case of json_parser.y. But it sure can use %define parse.error verbose to get better error messages.

What are the exact requirement for Bison? There are other features that would make sense here, but I guess you don't want to depend on the latest release.
Bison 3.6 will bring improvements to the error message generation; they should allow vastly simplify the complications of

php-src/Zend/zend_language_parser.y

Line 1320 in 1caf095

/* Copy to YYRES the contents of YYSTR after stripping away unnecessary

.

[nikic]

Our current Bison version requirement is 3.0. That can be raised, but we do require the version to be somewhat widely available, so 3.6 is not going to be an option (after all, it's not even released yet). If there's a way to make use of new features conditionally (depending on bison version), we could do that...

[nikic]

@carusogabriel I believe the JSON parser doesn't report any error messages (only error codes), so enabling verbose errors wouldn't do anything there.

[akimd]

Our current Bison version requirement is 3.0. That can be raised, but we do require the version to be somewhat widely available,

3.0 is already "very old" (end of 2013):

      3:* Noteworthy changes in release ?.? (????-??-??) [?]
     78:* Noteworthy changes in release 3.5.1 (2020-01-19) [stable]
     86:* Noteworthy changes in release 3.5 (2019-12-11) [stable]
    293:* Noteworthy changes in release 3.4.2 (2019-09-12) [stable]
    310:* Noteworthy changes in release 3.4.1 (2019-05-22) [stable]
    316:* Noteworthy changes in release 3.4 (2019-05-19) [stable]
    456:* Noteworthy changes in release 3.3.2 (2019-02-03) [stable]
    463:* Noteworthy changes in release 3.3.1 (2019-01-27) [stable]
    470:* Noteworthy changes in release 3.3 (2019-01-26) [stable]
    785:* Noteworthy changes in release 3.2.4 (2018-12-24) [stable]
    793:* Noteworthy changes in release 3.2.3 (2018-12-18) [stable]
    800:* Noteworthy changes in release 3.2.2 (2018-11-21) [stable]
    806:* Noteworthy changes in release 3.2.1 (2018-11-09) [stable]
    813:* Noteworthy changes in release 3.2 (2018-10-29) [stable]
    979:* Noteworthy changes in release 3.1 (2018-08-27) [stable]
   1119:* Noteworthy changes in release 3.0.5 (2018-05-27) [stable]
   1149:* Noteworthy changes in release 3.0.4 (2015-01-23) [stable]
   1161:* Noteworthy changes in release 3.0.3 (2015-01-15) [stable]
   1217:* Noteworthy changes in release 3.0.2 (2013-12-05) [stable]
   1241:* Noteworthy changes in release 3.0.1 (2013-11-12) [stable]
   1272:* Noteworthy changes in release 3.0 (2013-07-25) [stable]
   1868:* Noteworthy changes in release 2.7.1 (2013-04-15) [stable]

so 3.6 is not going to be an option (after all, it's not even released yet). If there's a way to make use of new features conditionally (depending on bison version), we could do that...

Sure, I do not plan to submit a PR for 3.6 right now. Yet I'll try 3.6 on PHP to make sure it will make your code simpler the day you merge it.