Commit graph

20052 commits

Author SHA1 Message Date
Sebastian Ullrich
43caef0130 fix: parenthesizer 2020-06-13 11:13:37 +02:00
Leonardo de Moura
6f0192581a feat: change precedence for fun and do parsing rules to maxPrec
Motivation: avoid `$`. See new test.

cc @Kha
2020-06-11 16:24:04 -07:00
Leonardo de Moura
7860f3645e doc: update comments to match new algorithm 2020-06-11 16:18:26 -07:00
Sebastian Ullrich
0afae3acc5 doc: adjust citation in Parser.lean 2020-06-11 15:55:53 -07:00
Leonardo de Moura
36bddc91cb chore: remove checkWsBeforeIfSymbol hack
Now the `app` parsing rule always require some whitespace before the
first argument.

cc @Kha
2020-06-11 14:58:29 -07:00
Leonardo de Moura
f0ebf426b7 chore: longestMatchFn parsers must produce exactly one Syntax node
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
2020-06-11 12:38:55 -07:00
Leonardo de Moura
8e4dc5bcf6 fix: longestMatchFn
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
2020-06-11 12:21:16 -07:00
Leonardo de Moura
77ce102baf chore: use notationItem to remove $noprec* hack 2020-06-10 16:59:44 -07:00
Leonardo de Moura
d9f71c6921 chore: update stage0 2020-06-10 16:55:40 -07:00
Leonardo de Moura
de0a2fefa0 feat: add notationItem 2020-06-10 16:54:46 -07:00
Leonardo de Moura
610ced2de5 chore: appPrec => maxPrec 2020-06-10 16:50:09 -07:00
Leonardo de Moura
f92166e913 chore: fix test 2020-06-10 16:43:44 -07:00
Leonardo de Moura
f838b80e03 fix: elaboration functions for parser! and tparser! 2020-06-10 16:42:42 -07:00
Leonardo de Moura
b5dff38ecf chore: update stage0 2020-06-10 16:22:32 -07:00
Leonardo de Moura
7269a721ff fix: parser! and tparser! syntax in the new frontend 2020-06-10 16:20:48 -07:00
Leonardo de Moura
1307405300 chore: make sure parser! and tparser! use a syntax similar to the one used at syntax for setting precedences
cc @Kha
2020-06-10 16:09:13 -07:00
Leonardo de Moura
243cda497e chore: remove leadingNodePrec and trailingNodePrec 2020-06-10 15:07:41 -07:00
Leonardo de Moura
cdc2dbe28d chore: use leadingNode and trailingNode in the old frontend 2020-06-10 15:05:22 -07:00
Leonardo de Moura
1c09e63a29 chore: update trailingNode and leadingNode API 2020-06-10 15:02:12 -07:00
Leonardo de Moura
6e848c484e chore: update stage0 2020-06-10 14:58:52 -07:00
Leonardo de Moura
1477d23546 feat: remove ParserDescr.prec and update ParserDescr.trailingNode/ParserDescr.node 2020-06-10 14:57:55 -07:00
Leonardo de Moura
74b4ef55f4 chore: update stage0 2020-06-10 14:45:33 -07:00
Leonardo de Moura
2125687d9c chore: remove unnecessary [appPrec] annotations 2020-06-10 14:44:54 -07:00
Leonardo de Moura
80928e6494 chore: update stage0 2020-06-10 14:40:23 -07:00
Leonardo de Moura
ca018d561e chore: update parser! and tparser! macros in the old frontend 2020-06-10 14:39:33 -07:00
Leonardo de Moura
77e1260ed2 chore: simplify checkPrec 2020-06-10 14:34:58 -07:00
Leonardo de Moura
a677c18683 chore: update stage0 2020-06-10 13:46:43 -07:00
Leonardo de Moura
6d3aff97d5 chore: lbp and rbp ==> prec 2020-06-10 13:41:10 -07:00
Leonardo de Moura
f0a9e54a69 chore: make sure leading and trailing parsers use the same kind of check 2020-06-10 13:41:10 -07:00
Sebastian Ullrich
894098dcc3 chore: de-Nix-ify macOS binary 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
7ecdb8d5ee chore: update Windows CI 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
6019c30a37 chore: remove obsolete MinGW-specific flag 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
8ae25090cf chore: add separate "Linux release" CI job using Nix channel with older glibc for compatibility 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
40463a3ab8 chore: building static executables is hopeless, do mostly static instead 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
485a1d67f8 chore: update CI 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
97fd4e7a87 chore: CI: upload build artifact; remove unused LLVM=ON job 2020-06-10 21:30:38 +02:00
Sebastian Ullrich
6e2b852182 chore: bump minimum cmake version
Apparently cmake 3.10 doesn't like custom `test` targets even when not using CTest in the project

/cc @leodemoura
2020-06-10 21:30:38 +02:00
Leonardo de Moura
f23780a334 chore: add hack for allowing old and new frontends to parse Core.lean 2020-06-09 14:11:34 -07:00
Leonardo de Moura
e62e30ad0f chore: remove whitespace 2020-06-09 14:11:34 -07:00
Leonardo de Moura
85320d9cf0 chore: add support for old syntax 2020-06-09 14:11:34 -07:00
Leonardo de Moura
25c1986439 chore: fix tests 2020-06-09 14:11:34 -07:00
Leonardo de Moura
7ec23f9401 fix: macro command syntax 2020-06-09 14:11:34 -07:00
Leonardo de Moura
a4f19aac32 fix: macro command 2020-06-09 14:11:34 -07:00
Leonardo de Moura
7fce8b5d1f fix: notation command
@Kha Note that I had to write the weird pattern

```
match_syntax stx with
| `(notation:$prec $items* => $rhs)    => expandNotationAux stx prec items rhs
| `(notation $noprec* $items* => $rhs) => expandNotationAux stx none items rhs
| _ => Macro.throwUnsupported
```

with the weird `$noprec*` to match the case where the optional
precedence is not provided. I realized this is not a bug, but
I guess most users will be puzzled by this behavior. If we had a kind
for `notationItem`, I would be able to write
```
`(notation $items:notationItems* => $rhs)
```
2020-06-09 14:11:34 -07:00
Sebastian Ullrich
a78ceb8121 fix: parenthesizer 2020-06-09 11:26:00 +02:00
Sebastian Ullrich
c8ee21747b chore: remove obsolete symbolAux, symbolNoWsAux 2020-06-09 10:37:00 +02:00
Leonardo de Moura
4250bc630e chore: fix tests 2020-06-08 16:18:46 -07:00
Leonardo de Moura
2b58ecea60 chore: fix test 2020-06-08 16:13:52 -07:00
Leonardo de Moura
f46dcd7a13 chore: fix some tests 2020-06-08 16:12:06 -07:00
Leonardo de Moura
aa49b3cdb1 feat: elaborate new syntax command 2020-06-08 16:12:06 -07:00