Improve syntax error reporting
kaikalur opened this issue · comments
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
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).
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
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