[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/7] Deprecate yysyntax_error_arguments
From: |
Akim Demaille |
Subject: |
Re: [PATCH 0/7] Deprecate yysyntax_error_arguments |
Date: |
Thu, 26 Mar 2020 19:10:00 +0100 |
> Le 26 mars 2020 à 19:09, Akim Demaille <address@hidden> a écrit :
>
>
>
>> Le 21 mars 2020 à 12:53, Akim Demaille <address@hidden> a écrit :
>>
>> This series of commits explores the removal of
>> yysyntax_error_arguments, as Adrian suggested
>> (https://lists.gnu.org/archive/html/bison-patches/2020-02/msg00069.html).
>> I wanted to see in practice what impact it has on the user code, and
>> here are a few examples.
>
> I have still not applied these changes, I would be happy to receive
> comments. But there are a few more patches to add.
>
> commit f1eb1e197d7453579f7843315a0aca0a2563ca90
> Author: Akim Demaille <address@hidden>
> Date: Thu Mar 26 08:15:35 2020 +0100
>
> skeletons: make yysyntax_error_arguments a private detail
And this one.
commit 8ce89cbc0b7c381a0bb7408d010d0b8fc1926148
Author: Akim Demaille <address@hidden>
Date: Thu Mar 26 08:35:50 2020 +0100
java: make yysyntaxErrorArguments a private detail
* data/skeletons/lalr1.java (yysyntaxErrorArguments): Move it from the
context, to the parser object.
Generate only for detailed and verbose error messages.
* tests/local.at (AT_YYERROR_DEFINE(java)): Use yyexpectedTokens
instead.
diff --git a/data/skeletons/lalr1.java b/data/skeletons/lalr1.java
index c5cbd1be..195fed1a 100644
--- a/data/skeletons/lalr1.java
+++ b/data/skeletons/lalr1.java
@@ -933,46 +933,49 @@ b4_dollar_popdef[]dnl
{
return ]b4_parser_class[.yysymbolName (yysymbol);
}
+ }
- int yysyntaxErrorArguments (int[] yyarg, int yyargn)
- {
- /* There are many possibilities here to consider:
- - If this state is a consistent state with a default action,
- then the only way this function was invoked is if the
- default action is an error action. In that case, don't
- check for expected tokens because there are none.
- - The only way there can be no lookahead present (in tok) is
- if this state is a consistent state with a default action.
- Thus, detecting the absence of a lookahead is sufficient to
- determine that there is no unexpected or expected token to
- report. In that case, just report a simple "syntax error".
- - Don't assume there isn't a lookahead just because this
- state is a consistent state with a default action. There
- might have been a previous inconsistent state, consistent
- state with a non-default action, or user semantic action
- that manipulated yychar. (However, yychar is currently out
- of scope during semantic actions.)
- - Of course, the expected token list depends on states to
- have correct lookahead information, and it depends on the
- parser not to perform extra reductions after fetching a
- lookahead from the scanner and before detecting a syntax
- error. Thus, state merging (from LALR or IELR) and default
- reductions corrupt the expected token list. However, the
- list is correct for canonical LR with one exception: it
- will still contain any token that will not be accepted due
- to an error action in a later state.
- */
- int yycount = 0;
- if (this.yytoken != yyempty_)
- {
- yyarg[yycount++] = this.yytoken;
- yycount += this.yyexpectedTokens (yyarg, 1, yyargn);
- }
- return yycount;
- }
+]b4_parse_error_bmatch(
+[detailed\|verbose], [[
+ private int yysyntaxErrorArguments (Context yyctx, int[] yyarg, int yyargn)
+ {
+ /* There are many possibilities here to consider:
+ - If this state is a consistent state with a default action,
+ then the only way this function was invoked is if the
+ default action is an error action. In that case, don't
+ check for expected tokens because there are none.
+ - The only way there can be no lookahead present (in tok) is
+ if this state is a consistent state with a default action.
+ Thus, detecting the absence of a lookahead is sufficient to
+ determine that there is no unexpected or expected token to
+ report. In that case, just report a simple "syntax error".
+ - Don't assume there isn't a lookahead just because this
+ state is a consistent state with a default action. There
+ might have been a previous inconsistent state, consistent
+ state with a non-default action, or user semantic action
+ that manipulated yychar. (However, yychar is currently out
+ of scope during semantic actions.)
+ - Of course, the expected token list depends on states to
+ have correct lookahead information, and it depends on the
+ parser not to perform extra reductions after fetching a
+ lookahead from the scanner and before detecting a syntax
+ error. Thus, state merging (from LALR or IELR) and default
+ reductions corrupt the expected token list. However, the
+ list is correct for canonical LR with one exception: it
+ will still contain any token that will not be accepted due
+ to an error action in a later state.
+ */
+ int yycount = 0;
+ if (yyctx.getToken () != yyempty_)
+ {
+ yyarg[yycount++] = yyctx.getToken ();
+ yycount += yyctx.yyexpectedTokens (yyarg, 1, yyargn);
+ }
+ return yycount;
}
+]])[
- /**
+/**
* Report a syntax error.
*/
private void yyreportSyntaxError (Context yyctx)
@@ -984,7 +987,7 @@ b4_dollar_popdef[]dnl
{
final int argmax = 5;
int[] yyarg = new int[argmax];
- int yycount = yyctx.yysyntaxErrorArguments (yyarg, argmax);
+ int yycount = yysyntaxErrorArguments (yyctx, yyarg, argmax);
String[] yystr = new String[yycount];
for (int yyi = 0; yyi < yycount; ++yyi)
yystr[yyi] = yysymbolName (yyarg[yyi]);
diff --git a/tests/local.at b/tests/local.at
index 5cc51e7e..fdb715c9 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -972,17 +972,24 @@ m4_define([AT_YYERROR_DEFINE(java)],
]AT_ERROR_CUSTOM_IF([[
public void yyreportSyntaxError (Calc.Context ctx)
{
- int[] arg = new int[ctx.NTOKENS];
- int n = ctx.yysyntaxErrorArguments (arg, ctx.NTOKENS);
System.err.print (]AT_LOCATION_IF([[ctx.getLocation () + ": "]]
- + )["syntax error on token @<:@" + ctx.yysymbolName
(arg[0]) + "@:>@");
- if (1 < n)
- {
- System.err.print (" (expected:");
- for (int i = 1; i < n; ++i)
- System.err.print (" @<:@" + ctx.yysymbolName (arg[i]) + "@:>@");
- System.err.print (")");
- }
+ + )["syntax error");
+ {
+ int token = ctx.getToken ();
+ if (token != ctx.EMPTY)
+ System.err.print (" on token @<:@" + ctx.yysymbolName (token) +
"@:>@");
+ }
+ {
+ int[] arg = new int[ctx.NTOKENS];
+ int n = ctx.yyexpectedTokens (arg, ctx.NTOKENS);
+ if (0 < n)
+ {
+ System.err.print (" (expected:");
+ for (int i = 0; i < n; ++i)
+ System.err.print (" @<:@" + ctx.yysymbolName (arg[i]) + "@:>@");
+ System.err.print (")");
+ }
+ }
System.err.println ("");
}
]])
- [PATCH 0/7] Deprecate yysyntax_error_arguments, Akim Demaille, 2020/03/21
- [PATCH 1/7] doc: c++: promote api.token.raw, Akim Demaille, 2020/03/21
- [PATCH 2/7] style: reduce length of private constant, Akim Demaille, 2020/03/21
- [PATCH 5/7] tests: yacc.c: avoid yysyntax_error_arguments, Akim Demaille, 2020/03/21
- [PATCH 3/7] yacc.c: use negative numbers for errors in auxiliary functions, Akim Demaille, 2020/03/21
- [PATCH 4/7] examples: don't use yysyntax_error_arguments, Akim Demaille, 2020/03/21
- [PATCH 7/7] lalr1.cc: avoid using yysyntax_error_arguments, Akim Demaille, 2020/03/21
- [PATCH 6/7] bison: avoid using yysyntax_error_arguments, Akim Demaille, 2020/03/21
- Re: [PATCH 0/7] Deprecate yysyntax_error_arguments, Akim Demaille, 2020/03/26
- Re: [PATCH 0/7] Deprecate yysyntax_error_arguments,
Akim Demaille <=