1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
//! First-party lexer, parser, AST, binder, semantic rewrites, and logical and
//! physical plans.
//!
//! Invariant: the SQL front end is pure. It parses, binds, plans and compiles;
//! it opens no file, reads no page, and holds no connection. Everything it
//! needs to know about a schema arrives through [`catalog_view::CatalogView`],
//! which is a read-only view someone else has already built.
//!
//! That interface is why this crate sits *below* `inillucent-catalog` rather than
//! above it. The catalog has to parse the CREATE text stored in
//! `sqlite_schema` with this parser, and a crate cannot be both above and below
//! another; the parser is the more fundamental half, so it goes underneath and
//! the catalog implements the view.
//!
//! Module map, in the order SQL moves through them:
//!
//! - [`keyword`] - the pinned release's keyword table and its fallback rule;
//! - [`lexer`] - bytes to tokens, zero copy, with spans;
//! - [`precedence`] - the operator table, as data;
//! - [`ast`] - the arena and every node kind;
//! - [`diagnostic`] - syntax failures, with offsets;
//! - [`parser`] - recursive descent for statements, Pratt for expressions;
//! - [`catalog_view`] - what the binder is allowed to know about a schema;
//! - [`bind`] - names to columns, and the bound relational tree;
//! - [`plan`] - the logical and physical plans the compiler walks.
// Tests assert on exact values and are allowed to fail loudly; the bans above
// exist to keep panics and wrapping out of paths that read caller input.
pub use ;
pub use ;
pub use ;
pub use ;
/// The implementation phase that filled this crate in, as named by the TDD.
pub const IMPLEMENTATION_PHASE: &str = "phase 5: lexer, parser, AST, and syntax parity";