Hi Adela, > Le 7 nov. 2020 à 16:25, Adela Vais <[email protected]> a écrit : > > Hello, > > I opened a PR.
Excellent! I was able to install this fine patch. There's a lot of work in it, thanks! > From 43ee2dbb3e10fd9ef677e94528a1a2c78f1303b3 Mon Sep 17 00:00:00 2001 > From: Adela Vais <[email protected]> > Date: Sat, 24 Oct 2020 16:43:46 +0300 > Subject: [PATCH for Dlang support 2/2] d: add the custom error message > feature > > Parser.Context class returns a const YYLocation, so Lexer's method > yyerror() needs to receive the location as a const parameter. > > Internal error reporting flow is changed to be similar to that of > the other skeletons. Before, case YYERRLAB was calling yyerror() > with the result of yysyntax_error() as the string parameter. As the > custom error message lets the user decide if they want to use > yyerror() or not, this flow needed to be changed. Now, case YYERRLAB > calls yyreportSyntaxError(), that builds the error message using > yysyntaxErrorArguments(). Then yyreportSyntaxError() passes the > error message to the user defined syntax_error() in case of a custom > message, or to yyerror() otherwise. > > In the tests in tests/calc.at, the order of the tokens needs to be > changed in order of precedence, so that the D program outputs the > expected tokens in the same order as the other parsers. > > * data/skeletons/lalr1.d: Add the custom error message feature. > * doc/bison.texi: Document it. > * examples/d/calc/calc.y: Adjust. > * tests/calc.at, tests/local.at: Test it. I'm also installing the following patch. commit 10eb13007efb29b48455bb0b317be59f07fb901a Author: Akim Demaille <[email protected]> Date: Sat Nov 7 17:12:21 2020 +0100 d: remove dead comment * data/skeletons/lalr1.d (reportSyntaxError): here. diff --git a/data/skeletons/lalr1.d b/data/skeletons/lalr1.d index c85c712c..73ece8ff 100644 --- a/data/skeletons/lalr1.d +++ b/data/skeletons/lalr1.d @@ -677,37 +677,6 @@ m4_popdef([b4_at_dollar])])dnl [custom], [[ yylexer.syntax_error(yyctx);]], [detailed\|verbose], [[ - /* There are many possibilities here to consider: - - Assume YYFAIL is not used. It's too flawed to consider. - See - <http://lists.gnu.org/archive/html/bison-patches/2009-12/msg00024.html> - for details. YYERROR is fine as it does not invoke this - function. - - 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. - */ if (yyctx.getToken() != ]b4_symbol(empty, kind)[) { // FIXME: This method of building the message is not compatible
