@Kha It is not clear why this change fixed the build on my
Linux (running on VirtualBox). The issue seems to be due
circular dependencies between the static libraries, and the order the
static libraries are processed. Note that the build worked on my OSX
without this change.
@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
