Hi Rici! > Le 27 sept. 2020 à 20:46, Rici Lake <[email protected]> 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!
