Re: multistart: yynerrs

[Akim Demaille]

Hi Rici!

> Le 27 sept. 2020 à 20:46, Rici Lake <ricilake@gmail.com> a écrit :
[...]
>     SomeValueType result;
>     if (yyparse_expression(&result) != YYSUCCESS) {
>        /* signal error and don't try to process value */
>     }
> 
> That doesn't address the question of the yynerrs member, which probably
> needs more thought. But in general, I don't think that yynerrs is a very
> general solution. It seems necessary, but it will often not be sufficient.
> In many ways, it's an unhappy proxy for the absence of a way to influence
> the status return.

Well, it may also participate in a global count of errors, with a
threshold to avoid overflowing the user with too many error messages.

But I agree that most of the time its effective value is irrelevant,
only there were errors or not matters.


> In a parser with error recovery, some (possibly all)
> errors will render the value result invalid,

Well, in that case the error recovery is poor.  Error recovery should
return a sane value, that the whole point of error rules.  For instance,
error recovery should return a valid AST, possibly with special nodes
marking places where there were errors, but certainly not returning
a broken AST.  Without these provisions, one will not be able to run
other checks, say type checking, after syntax errors.


> but there is no interface
> which tells yyparse that it should return "PARSED_WITH_ERRORS" instead of
> YYSUCCESS.

We could give the user a means to set the return value, indeed.  Its
range (int) is currently largely underused :)

> But using yynerrs for this purpose is not ideal either;
> integrating that test into the above code samples reveals how annoying it
> is. Furthermore, many parsers will want to have a much more articulated
> datum for reporting: severe errors; errors; just warnings; no diagnostics
> at all. And at least some parsers might prefer to have diagnostics
> accumulated in some kind of diagnostic container type, which is produced as
> part of the final result. (See clanglib, for example.)

Exactly.

These case should be handled in one of these "parser_control"
structures covered in the documentation (called "driver" in the C++ sections).
Use %parse-param to make it available during the parse, and in particular in
yyerror, which, instead of emitting the error, just stores it.


Cheers!