Improve syntax error reporting

[kaikalur]

Due to (mostly) direct translation of the spec and especially keeping the expressions part as given in the spec, some syntax errors are not very good. For example:

SELECT Overlaps( overlaps ) AS overlaps;

Gives a bad error:

Parse error: 1:1 at token: SELECT

One simple addition would be to see if the next token (after the consumed token SELECT) is a keyword and use that as an error. So fro the above, it will be better to say:

Parse error: 1:8 at token: OVERLAPS

[manticore-projects]

Can we maybe also state the Production where it fails?
Based on a Rail Road Diagram, for the example above this would point straight to: "Reserved Keyword where Identifier has been expected" (which in my experience accounts for 50% of all end user issues).

[kaikalur]

No production is a concept for the developer, not the user. Again - you can just customize it for your usecase if you want to add the production, but I don't want it in the main grammar

[kaikalur]

Can we maybe also state the Production where it fails? Based on a Rail Road Diagram, for the example above this would point straight to: "Reserved Keyword where Identifier has been expected" (which in my experience accounts for 50% of all end user issues).

Yes that's the idea - so if the next token (token.next) is a reserved word, we give this error saying found keyword where identifier is expected