Re: [PATCH for Dlang support 2/2] d: add the custom error message feature

[Akim Demaille]

Hi Adela,

> Le 7 nov. 2020 à 16:25, Adela Vais <adela.vais99@gmail.com> 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 <adela.vais@yahoo.com>
> 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 <akim.demaille@gmail.com>
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