import { ParserRuleContext } from "antlr4ng";
import type { SyntaxDiagnostic } from "../parse-diagnostics.js";
/**
 * Collect post-parse syntax violations in the CST as positioned diagnostics. Each is one syntax error.
 *
 * - select_column_dot_star: googlesql.tm binds `.*` at `.` precedence (`%prec "."`), so the base must be
 *   a postfix expression (`t.*`, `(a+b).*`, `f(x).*`), not a binary one — `a+b.*` parses as `a + (b.*)`
 *   and fails on `*` ("Unexpected *"). A base carrying a top-level binary operator is invalid.
 * - shift_operator `>>`: the grammar recombines two `>` tokens so nested generics close
 *   (`ARRAY<STRUCT<INT64>>`), but ZetaSQL only lexes `>>` when the two `>` are ADJACENT. With a space —
 *   `1 > > 2` — they are two comparison operators and chaining them is "Unexpected >".
 * - SELECT WITH <kind> OPTIONS(...): `WITH kind OPTIONS(…)` is the differential-privacy with-clause's
 *   own OPTIONS, leaving an empty SELECT list ("SELECT list must not be empty" / "Unexpected ,"). ANTLR
 *   instead reads `OPTIONS(…)` as a select item (so the with-clause has no OPTIONS); detect that shape —
 *   a `WITH <id>` with no OPTIONS whose first select item is an `OPTIONS(…)` call — and reject it.
 * - CALL tvf suffixes: googlesql.tm `pipe_call` is `CALL tvf as_alias?` (no PIVOT/UNPIVOT) and a graph
 *   `CALL … tvf` takes a bare tvf (no alias, no pivot). Our shared tvf_with_suffixes permits both, so
 *   flag a pipe CALL with a PIVOT/UNPIVOT, and a graph CALL with any tvf alias/pivot suffix.
 * - pipe AGGREGATE dot-star order: googlesql.tm's pipe_selection_item_with_order allows an ASC/DESC
 *   order only on an expression item, not on a dot-star (`|> AGGREGATE s.* ASC`).
 * - LIKE ANY/SOME/ALL chained on a comparison: `'1' IN (…) LIKE ANY (…)` — the LIKE-quantified alts
 *   lack the inline non-associativity guard the plain comparison alts have, so a comparison-family LHS
 *   ("Expression to the left of LIKE must be parenthesized") slips through.
 * - ANALYZE OPTIONS: `OPTIONS` after ANALYZE commits to the OPTIONS keyword (which needs `(...)`), so
 *   `ANALYZE OPTIONS` / `ANALYZE OPTIONS, T` — where it is read as a table name — is a syntax error.
 * - standalone subpipeline: a bare `|> …` subpipeline is its own single-statement entry in ZetaSQL, so
 *   it can't be one of several `;`-separated statements (`|> WHERE true; |> WHERE false`, `|> DESCRIBE;
 *   SELECT 1` → "Expected end of input"/"Unexpected"). It must be the sole top-level statement.
 * - IN value-list hint: a `@{…}` hint on `IN (value, …)` is "HINTs cannot be specified on IN clause with
 *   value list" (the grammar already rejects the UNNEST form inline; the value-list form is here).
 * - lambda argument list: a lambda parameter list must be a path or a parenthesized struct (`(e, i>0)`),
 *   not a query (`(SELECT 1) -> …`) — "Expecting lambda argument list". The grammar's getText()-based
 *   check misses keyword boundaries; re-validated here on spaced text.
 */
export declare function postParseDiagnostics(tree: ParserRuleContext): SyntaxDiagnostic[];