Parse-postfix-expression
Parse a postfix expression.
- Signature
(parse-postfix-expression parstate)
→
(mv erp expr span new-parstate)
- Arguments
- parstate — Guard (parstatep parstate).
- Returns
- expr — Type (exprp expr).
- span — Type (spanp span).
- new-parstate — Type (parstatep new-parstate), given (parstatep parstate).
A postfix expression may start with a primary expression
or with a parenthesized type name,
both of which start with an open parenthesis.
So we need to read a token, and see if it is an open parenthesis.
If it is not, we must have
a postfix expression that starts with a primary expression:
we put back the token,
parse a primary expression,
and then parse the rest of the postfix expression
via a separate function (see that function's) documentation.
Note that if the parsing of the primary expression fails,
the error message mentions the possibility of an open parenthesis,
which thus covers the case of a parenthesized type name as well.
If the token is an open parenthesis,
we read a second token:
- If this second token is an identifier, things are still ambiguous.
We describe the handling of this case below,
after describing the other cases, which are simpler.
- If this second token may start an expression
but is not an identifier (the case above),
then we have a parenthesized expression
that is a primary expression that starts the postfix expression.
We put back the token,
we parse an expression,
we read the closing parenthesis,
and we parse the rest of the postfix expression
via a separate function.
- If this second token may start a type name,
but is not an identifier (the first case above),
we must have a compound literal.
We put back the token,
parse a type name,
read a closing parenthesis,
and call a separate function to finish parsing the compound literal.
- If this second token is none of the above, including an absent token,
it is an error, whose message mentions
the possible starts of expressions and type names.
Now we describe the more complex case above,
where we have an open parenthesis and an identifier.
We read a third token:
- If this third token is a closed parenthesis,
things are still ambiguous, because we could have
either a parenthesized expression or a parenthesized type name.
We describe this case below, after describing the other cases,
which are simpler.
- If this third token may be the rest of a postfix expression,
we put back the token and parse an expression.
Then we parse a closing parenthesis,
and this is a primary expression:
we parse the rest of the postfix expression (if any).
- If this third token is none of the above, it is an error.
Now we describe the more complex case above,
where we have a parenthesized identifier,
which could be either an expression or a type name.
We read a fourth token, and consider these cases:
- If this fourth token is an open curly brace,
we have resolved the ambiguity.
The postfix expression is a compound literal.
We put back the curly brace
and we call a separare function to parse
the rest of the compound literal.
- If this fourth token may start the rest of a postfix expression,
we have also resolved the ambiguity:
the identifier must be an expression,
and we parse the rest of the postfix expression
after putting back the token.
- If this fourth token is none of the above,
we have an error.