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
ParseErrorListener
methods -- and also things likeexception_parsing
,exception_scanning
andon_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
callsdriver.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 onstderr
before re-raising the original exception.