Various things would be easier if there were a consistent format for diagnostic data passed into all the ParseErrorListener methods -- and also things like exception_parsing, exception_scanning and on_stuck. Have convenient methods to inspect the parse stack, scan state, and next-token, and the human-readable action/constructor name (as applicable) without acrobatics.
parse_action_bindings calls driver.exception_parsing(ex, cid, args). This should really move into shift_reduce.parse.reduce_by_rule, and onto ParseErrorListener. Maybe default behavior is to print diagnostic data on stderr before re-raising the original exception.
Various things would be easier if there were a consistent format for diagnostic data passed into all the
ParseErrorListenermethods -- and also things likeexception_parsing,exception_scanningandon_stuck. Have convenient methods to inspect the parse stack, scan state, and next-token, and the human-readable action/constructor name (as applicable) without acrobatics.parse_action_bindingscallsdriver.exception_parsing(ex, cid, args). This should really move intoshift_reduce.parse.reduce_by_rule, and ontoParseErrorListener. Maybe default behavior is to print diagnostic data onstderrbefore re-raising the original exception.