parser: invalid AST from input
Closed this issue · 1 comments
Describe the bug
A fuzzing run exposed the following statements, that are not valid by our SQL grammar, but produce an invalid AST without raising errors.
-
SELECT+FROM L( #165 ) -
SELECT FROM a( #164 ) -
SELECT(* OM L -
SELECT*FROM y LIMIT -,0
The-indicates a unary expression, but the expression of the unary expression isnil, which causes a compiler panic -
SELECT~*0 -
VALUES(0<-,) -
VALUES(-) -
SELECT 0>0>~>0 -
SELECT 0>0>0>~>0 -
SELECT 0>0>0>0>~>0 -
SELECT 0>0>0>0>0>~>0 -
SELECT 0>0>0>0>0>0>~>0 -
SELECT 0>0>0>0>0>0>0>~>0 -
SELECT 0>0>0>0>0>0>0>0>~>0
The last few (0>0>0) seem similar, however, the fuzzer only adds new input, when the input gives new coverage. They still will probably be fixed with the same code.
To Reproduce
Try to parse each statement. None of them is valid, however, no parse error is risen.
Expected behavior
One or more parse errors must be risen.
Additional notes
Every one of these statements must first be confirmed to be a parser issue.
This is trivial for some, like the third one, which is an obviously incorrect statement.
However, most compiler panics come from dereferencing nil, meaning that the compiler expected a component of the ast where none was (most of the times).
If you can confirm, that one of the statements parses without errors, but produces a valid AST and is a valid input according to our grammar, please add a comment to this issue.
All of these were fixed by adding a nil check in the entire parser to all expressions.
However, I need a double check from your side about the kind of errors.