blob: 235ecdb74f45a2792a236c6ed610506d8acbb7fa [file] [log] [blame] [view]
# Fuchsia Shell Parser
Provides a basic parser for the shell grammar.
The parser is built on combinators, which means the parser is built out of other parsers.
A parser in the source appears as a function taking a single argument of type `ParseResult` and
returning a value of type `ParseResult`. The argument is the result of parsing a prefix before the
current parse. As an example, consider the grammar:
```
S <- A B
```
Assuming we had parser functions for `A` and `B`, named `A()` and `B()` respectively, we could
implement `S` as follows:
```
ParseResult S(ParseResult prefix) {
return B(A(prefix));
}
```
A `ParseResult` represents a position in the string. If parsing fails completely, the returned
`ParseResult` is equal to `ParseResult::kEnd`, which tests `false` when used as a boolean.
Generally, we hope that a failed parse will be recovered, so we will always get a valid parse from
our grammar, but it may or may not contain error nodes where we had to recover a failure.
`ParseResult` contains three pieces of information: the "tail" of the parse, representing the
un-parsed data remaining after the parse, error statistics, which includes the number of errors and
the number of characters that were successfully parsed without error, and a stack, which contains
the AST nodes we have produced.
To understand the stack, consider our `A B` example above. After successfully parsing `S`, the stack
might contain two nodes:
```
Node::A("A") Node::B("B")
```
The `ParseResult`'s `node` accessor would yield `Node::B`, as it yields the top of the stack. We can
call `Reduce()` on a `ParseResult` to collapse the stack into a single node, so if we called
`Reduce<Node::S>()` on our result, we would end up with one node on the stack:
```
Node::S(children = { Node::A Node::B })
```
`Reduce()` will consume the entire stack by default. This is inconvenient for more complicated
parsers. To make `S` safe, we would insert a "marker node" to indicate the point in the stack where
`Reduce()` should stop consuming. Thus our implementation looks like this:
```
ParseResult S(ParseResult prefix) {
return B(A(prefix.Mark())).Reduce<Node::S>();
}
```
This pattern is somewhat unwieldy, so we implement several combinator functions to produce it
automatically. The `NT` ("NonTerminal") combinator takes a parser as input and automatically places
a `Mark()` before it and a `Reduce()` after it, while the `Seq` combinator runs two parsers in
sequence.
```
ParseResult S(ParseResult prefix) {
return NT<Node::S>(Seq(A, B));
}
```
## Error Handling in a Nutshell
To mark and recover an error during parsing, there are two special combinators: `ErInsert` and
`ErSkip`.
`ErSkip` takes a child parser, which it runs. If that child parser parses without error, the parsed
text is discarded and an error is inserted instead. Here's an example:
```
Alt(Expression, ErSkip("Expected expression before '%MATCH%'", OnePlus(AnyCharBut(";"))));
```
This parser would attempt to parse an expression, and if it can't find one, it will consume up to
the next semicolon and insert an error message. Note the `'%MATCH%'` in the message string; this
will be substituted for the text matched before the semicolon. The parse result moves ahead by the
length of the match, but the internal count of successfully-parsed characters (accessed via
`parsed_successfully()`) does not increase.
If the parser given to `ErSkip` doesn't match without error, `ErSkip` fails completely, so error
recovery does not occur.
`ErInsert` is more straightforward than `ErSkip`. It injects an error at the current parse position
without moving.
```
Alt(Expression, Alt(Token(";"), ErInsert("Expected semicolon")));
```