According to the definition at https://sqlite.org/lang_expr.html, SQL
expressions could be infinitely deep. For practicality, SQLite enforces
a maxiumum expression tree depth of 1000. Apply the same limit in
LibSQL to avoid stack overflow in the expression parser.
Fixes https://crbug.com/oss-fuzz/34859.
Rather than aborting when a LIMIT clause of the form 'LIMIT expr, expr'
is encountered, fail the parser with a syntax error. This will be nicer
for the user and fixes the following fuzzer bug:
https://crbug.com/oss-fuzz/34837
The EXISTS expression is a bit of an odd-man-out because it can appear
as any of the following forms:
EXISTS (select-stmt)
NOT EXISTS (select-stmt)
(select-stmt)
Which makes it the only keyword expression that doesn't require its
keyword to actually be used. The consequence is that we might come
across an EXISTS expression while parsing another expression type;
NOT would have triggered a unary operator expression, and an opening
parentheses would have triggered an expression chain.
Currently, every parse_*_statement method ends by parsing a semi-colon.
This will prevent nested statements, e.g. a SELECT statement may be
nested in a CREATE TABLE statement. Move the semi-colon expectation up
and out of the individual statement parsers.
Another common semantic is parsing an identifier of the form
"schema_name.table_name" / "table_name". Add a helper to do this work.
This helper does not parse any optional alias after the table name.
some syntaxes specify an alias using the AS keyword, some let the AS
keyword be optional, and others just parse it as an identifier. So
callers to this helper will just continue parsing the alias however
they require.
A quite common semantic emerged for parsing comma-separated expressions:
consume(TokenType::ParenOpen);
do {
// do something
if (!match(TokenType::Comma))
break;
consume(TokenType::Comma);
} while (!match(TokenType::Eof));
consume(TokenType::ParenClose);
Add a helper to do the bulk of the while loop.
Statements like SELECT, INSERT, and UPDATE also optionally include this
list, so move its parsing out of parse_delete_statement(). Since it will
appear before the actual statement, parse it first in next_statement();
then only parse for statements that are allowed to include the list.
Misread the graph: In the "WITH [RECURSIVE] common-table-expression"
section, common-table-expression is actually a repeating list. This
changes the parser to correctly parse this section as a list. Create a
new AST node, CommonTableExpressionList, to store both this list and the
boolean RECURSIVE attribute (because every statement that uses this list
also includes the RECURSIVE attribute beforehand).
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
https://sqlite.org/lang_expr.html
The entry point to using expressions, parse_expression(), is not used
by SQL::Parser in this commit. But there's so much here that it's easier
to grok as its own commit.
The following is a common (and soon to be *very* common) expression:
if (match(token_type))
consume();
Using consume_if() makes this a bit simpler and makes it less likely to
forget to invoke consume() after the match().
