Each parser context should have a queue of syntax errors. When one is found, the string message is added to the queue based on a SyntaxErrorFormatter.
SyntaxErrorFormatter should be have overridable methods, with a way of getting at source lines with an arrow pointing to a certain column.
There will be other error types that users will add to the list below when processing the AST.
Goals of this task are:
- All language targets should support overridable formatters with reasonable defaults, described below
- As proof of concept, extend the syntax error reporting for Hermes itself. Everything
raise Exception in factory.py should now report a syntax error
SyntaxErrorFormatter for each language should have the following syntax errors:
unexpected_token
Currently displayed as: "Unrecognized token on line x, column y..."
Occurs when a we expect one token and get another, This is a LEXER error
file.ext:1:5: error: Unrecognized token
int ♭ain(
^
Or add mode information
file.ext:1:2: error: Unrecognized token
Occurred while scanning an object
{♭"abc"
^
excess_tokens
Currently displayed as: "Finished parsing without consuming all tokens"
Occurs when we've hit a terminal state parsing but there are still tokens left. This might also be accompanied with an unexpected_symbol.
file.ext:1:2: error: Finished parsing without consuming all tokens
{}}
^
unexpected_eof
Currently displayed as: "unexpected end of file"
Occurs when we're parsing a nonterminal and it's supposed to consume tokens but there are none left. What happens if we just continue anyway?
file.ext:1:2: error: Unexpected end of file
Expecting: :string
{
^
$object = :lbrace list($key_value_pair, :comma) :rbrace -> Object(values=$1)
no_more_tokens
Currently displayed as: "No more tokens. Expecting ..."
Occurs when we call expect() and there's nothing left in the token stream. This could probably be the error that happens after unexpected_eof
file.ext:1:2: error: No more tokens left to consume
Expecting: :string, :lsquare, :lbrace, :integer
{"key":
^
$key_value_pair = :string :colon $value -> KeyValue(key=$0, value=$2)
invalid_terminal
Currently displayed as: "Invalid symbol ID ..."
Occurs when a terminal is invalid. Probably rarely usedWe should probably consume the token and continue if this is the case.
file.ext:1:2: error: Invalid terminal
Unsure how to process :unknown ("foobar")
$key_value_pair = :string :colon $value -> KeyValue(key=$0, value=$2)
unexpected_symbol
Currently displayed as: "Unexpected symbol (line {line}, col {col}) when parsing parse_{nt} ...")
This is a PARSER error, when we see a token that we weren't expecting. Perhaps throw it away and move on?
file.ext:1:5: error: Unexpected symbol when parsing $key_value_pair
Expecting (:colon) but got (:string)
{"abc" "def"}
^
Each parser context should have a queue of syntax errors. When one is found, the string message is added to the queue based on a SyntaxErrorFormatter.
SyntaxErrorFormatter should be have overridable methods, with a way of getting at source lines with an arrow pointing to a certain column.
There will be other error types that users will add to the list below when processing the AST.
Goals of this task are:
raise Exceptioninfactory.pyshould now report a syntax errorSyntaxErrorFormatter for each language should have the following syntax errors:
unexpected_token
Currently displayed as: "Unrecognized token on line x, column y..."
Occurs when a we expect one token and get another, This is a LEXER error
Or add mode information
excess_tokens
Currently displayed as: "Finished parsing without consuming all tokens"
Occurs when we've hit a terminal state parsing but there are still tokens left. This might also be accompanied with an unexpected_symbol.
unexpected_eof
Currently displayed as: "unexpected end of file"
Occurs when we're parsing a nonterminal and it's supposed to consume tokens but there are none left. What happens if we just continue anyway?
no_more_tokens
Currently displayed as: "No more tokens. Expecting ..."
Occurs when we call expect() and there's nothing left in the token stream. This could probably be the error that happens after unexpected_eof
invalid_terminal
Currently displayed as: "Invalid symbol ID ..."
Occurs when a terminal is invalid. Probably rarely usedWe should probably consume the token and continue if this is the case.
unexpected_symbol
Currently displayed as: "Unexpected symbol (line {line}, col {col}) when parsing parse_{nt} ...")
This is a PARSER error, when we see a token that we weren't expecting. Perhaps throw it away and move on?