@Kha I elaborated it as a definition. It works because we can now
reference Parser declarations in `syntax` command.
This change allowed us to replace `p.getArg 0` with `p` in the
`Websever` demo.
@Kha Note that I had to change the pattern. After I replaced,
```
syntax text : child
```
with
```
syntax Prelim.text : child
```
Thus, I wrote
```
`(child|$t:text)
```
as
```
`(child|$t)
```
It works for this example, but it may be a problem in general.
@Kha We can now delete the command
```
@[termParser] def childStxQuot : Parser :=
checkPrec maxPrec >> (node `Lean.Parser.Term.stxQuot $ symbol "`(child|" >> categoryParser `child 0 >> symbol ")")
```
from the web demo.
We only keep trying other macros if the macro `m` produced
`unsupportedSyntax`. If the macro produced an error, we keep the
error.
@Kha This should fix the web demo.
Before this commit, we were handling the following two abnormal cases:
1- `p` did not produce any `Syntax` node. `runLongestMatchParser`
would insert a `Syntax.missing`.
2- `p` produced more than one `Syntax` node on the
stack. `runLongestMatchParser` would combine all of them using a
`nullKind` node.
This feature was never used since we only use `longestMatchFn` to
process leading and trailing parsers. In both case, we create a node.
Moreover, if a bad parser is manually created, I think it is better to
fail than accept using `Syntax.missing` or a `nullKind` node. We would
only be postponing the problem since we don't have elaboration
functions for them.
cc @Kha
Several combinators (e.g., `checkNoWsBefore`) access the "leading
term" by retrieving the element on the top of the syntax stack.
However, the `longestMatchFn` was accumulating successful matches on
the syntax stack too. This commit makes sure the `longestMatchFn`
always push the "leading term" before trying a parser.
This commit also eliminates the `orelseFn` hack at `trailingLoopStep`.
Now, we use `longestMatchFn` for all parsers. Note that we have to add
a new combinator (`checkWsBeforeIfSymbol`) to make sure that `a[i]`
cannot be parsed by the `app` parsing rule.
Before removing the hack from `trailingLoopStep`,
`a[i]` was correctly parsed as an `arrayRef`. After the change,
the `app` parser is tried and it succeeds (IF we don't use
`checkWsBeforeIfSymbol`). It is an application using the list literal
`[i]`.
The `checkWsBeforeIfSymbol` ensures that `a[i]` is not a valid `app`.
cc @Kha
