The parser is called like this:
        verb(
    Parser parser(rules, states);
    parser.parse();
        )
The constructor performs no other tasks than initializing the Parser object.
tt(Rules) and tt(states) are still empty at this point.

The tt(parse) function was generated by bf(bisonc++)(1). It's better
understood from the grammar description tt(parser/grammar): The grammar's
start rule is
        verb(
    input:
        opt_directives
        section_delimiter
        rules
    ;
        )

tt(parser/inc/rules): The directives are not covered yet in this section. A
rule is defined as:
        verb(
    rules:
        rules _rule
    |
        // empty
    ;
        )

As a notational convention, all non-terminals not used outside of the file in
which they are defined start with an underscore. Furthermore, wherever
possible rules are defined before they are used. This cannot always be
accomplished, e.g., when defining indirectly recursive rules.

A tt(_rule) is a rule definition followed by a newline:
        verb(
    _rule:                      
        _rule_def '\n' reset
    ;                               
        )

The tt(reset) non-terminal merely calls tt(Parser::reset), preparing the
parser for the next rule, resetting various data members to their original,
begin-of-line states. See tt(parser/reset.cc) for details.

A tt(_rule_definition) may be empty, but usually it consists of a rule
optionally valid for a set of start conditions (tt(optMs_rule), or it is a
rule or series of rules embedded in a start condition compound (tt(msComound)):
        verb(
    _rule_def:
        // only an empty line is OK
    |
        // recovery from errors is OK: continue at the next line
        error       
    |
        optMs_rule
    |
        msCompound
    ;
        )
    The tt(msCompund) isn't interesting by itself, as it repeats
tt(optMs_rule), but without the start condition specifications for the individual
rules. 
    
    An tt(optMs_rule) is a rule (tt(_optMs_rule)), optionally followed by an
action:
        verb(
    optMs_rule:
            // just regular expressions, without an action block
        _optMs_rule 
    |
        // the scanner returns a block if it encounters a non-blank character
        // on a line after ws, unless the character is a '|'
        _optMs_rule action
        {
            assignBlock();
        }
    ;
        )

    An tt(_optMS_rule) defines one or more rules, sharing the same action
block: 
        verb(
    _optMs_rule:                             // after ORNL continue parsing
        _optMs_rule ORNL '\n' reset _optMs_rule // at a new line
        {
            orAction();
        }
    |
        _optMs_regex
        {
            addRule($1, true);  // true: reset the miniscanner spec to INITIAL
        }
    ;
        )
    And an tt(_optMS_regex), finally, is a regular expression or EOF-pattern,
optionally prefixed by a start condition specification:
        verb(
    _optMs_regex:       
        ms_spec regexOrEOF
        {
            $$ = $2;
        }
    |
        regexOrEOF
    ;
        )
    A tt(regexOrEOF) defines exactly that:
        verb(
    regexOrEOF:
        _regex
    |
        EOF_PATTERN
        {
            $$ = eofPattern();
        }
    ;
        )
    
Actions are defined link(here)(BLOCKS); the tt(Rules) class is described
link(here)(RULES); Regular expressions (i.e., tt(regex)) are described
link(here)(PATTERNS).








