Struct Parser 

pub struct Parser {
    tokens: Vec<Token>,
    error: ErrorEmitter,
}

Fields

tokens: Vec<Token>

error: ErrorEmitter

Implementations

impl Parser

pub fn new(filename: &str, source: Chars<'_>, tokens: Vec<Token>) -> Self

pub fn parse( &self, ) -> Result<(String, u32, Vec<Constant>, Vec<Witness>, Vec<Statement>)>

fn parse_header<'a>( &self, iter: &mut impl Iterator<Item = &'a Token>, ) -> Result<u32>

Parse the file header: k=N; field=“…”;

The first thing that has to be declared in the source code is the constant “k” which defines 2^k rows that the circuit needs to successfully execute.

Then we declare the field we’re working in.

fn parse_sections<'a>( &self, iter: &mut impl Iterator<Item = &'a Token>, ) -> Result<(String, SectionTokens)>

Parse all sections (constant, witness, circuit) and return their tokens.

Sections “constant”, “witness”, and “circuit” are the sections we must be declaring in our source code. When we find one, we’ll take all the tokens found in the section and place them in their respective vec.

NOTE: Currently this logic depends on the fact that the sections are closed off with braces. This should be revisited later when we decide to add other lang functionality that also depends on using braces.

fn absorb_section_tokens<'a>( &self, iter: &mut impl Iterator<Item = &'a Token>, dest: &mut Vec<Token>, ) -> Result<()>

Absorb tokens from iterator until a closing brace is found. Validates that no keywords are used in improper places.

fn validate_section_namespace( &self, section_name: &str, tokens: &[Token], existing_ns: Option<String>, ) -> Result<String>

Validate namespace consistency across sections. All sections must use the same namespace, and it must not be a reserved name.

fn build_constants(&self, tokens: &[Token]) -> Result<Vec<Constant>>

Build constants from section tokens. Validates constant types against the CONSTANT_TYPES table.

fn build_witnesses(&self, tokens: &[Token]) -> Result<Vec<Witness>>

Build witnesses from section tokens.

fn parse_typed_section( &self, section_name: &str, tokens: &[Token], ) -> Result<IndexMap<String, (Token, Token)>>

Parse a typed section (constant or witness) into an IndexMap. Both sections have the same structure: pairs of ‘ ’ separated by commas.

fn validate_section_entry( &self, section_type: &str, name: &str, name_token: &Token, type_token: &Token, ) -> Result<()>

Common validation for constant/witness entries. Ensures name and type tokens are symbols and match expected values.

fn check_section_structure(&self, section: &str, tokens: &[Token]) -> Result<()>

Routine checks on section structure. Validates that sections have proper opening/closing braces and correct element counts.

fn parse_ast_circuit(&self, tokens: &[Token]) -> Result<Vec<Statement>>

Parse the circuit section into statements.

The statement layouts/syntax in the language are as follows:

C = poseidon_hash(pub_x, pub_y, value, token, serial);
| |          |                   |       |
V V          V                   V       V
variable    opcode              arg     arg
assign

                   constrain_instance(C);
                      |               |
                      V               V
                    opcode           arg

                                             inner opcode arg
                                              |
                 constrain_instance(ec_get_x(foo));
                       |                 |
                       V                 V
                    opcode          arg as opcode

In the latter, we want to support nested function calls, e.g.:

constrain_instance(ec_get_x(token_commit));

The inner call’s result would still get pushed on the heap, but it will not be accessible in any other scope.

In certain opcodes, we also support literal types, and the opcodes can return a variable type after running the operation. e.g.

one = witness_base(1);
zero = witness_base(0);

The literal type is used only in the function call’s scope, but the result is then accessible on the heap to be used by further computation.

Regarding multiple return values from opcodes, this is perhaps not necessary for the current language scope, as this is a low level representation. Note that it could be relatively easy to modify the parsing logic to support that here. For now we’ll defer it, and if at some point we decide that the language is too expressive and noisy, we’ll consider having multiple return types. It also very much depends on the type of functions/opcodes that we want to support.

fn validate_statement_brackets(&self, statement: &[Token]) -> Result<()>

Validate matching brackets in a statement. Ensures parentheses and brackets are balanced and properly nested.

fn parse_statement( &self, iter: &mut Peekable<Iter<'_, Token>>, ) -> Result<Statement>

Parse a single statement from tokens. Determines if this is an assignment (var = …) or a direct call (opcode(…)).

fn parse_opcode_call( &self, token: &Token, iter: &mut Peekable<Iter<'_, Token>>, stmt: &mut Statement, ) -> Result<()>

Parse an opcode call and fill in the statement. The assumption here is that the current token is a function call, so we check if it’s legit and start digging.

fn parse_function_call( &self, token: &Token, iter: &mut Peekable<Iter<'_, Token>>, ) -> Result<Vec<Arg>>

Parse a function call and its arguments. Handles nested function calls recursively, creating intermediate variables for inner call results.

fn expect_token_type(&self, token: &Token, expected: TokenType) -> Result<()>

Check that a token has the expected type.

fn next_tuple3<I, T>(iter: &mut I) -> Option<(T, T, T)>

where I: Iterator<Item = T>,

Get next 3 items from an iterator as a tuple.

fn next_tuple4<I, T>(iter: &mut I) -> Option<(T, T, T, T)>

where I: Iterator<Item = T>,

Get next 4 items from an iterator as a tuple.