Commit graph

20482 commits

Author SHA1 Message Date
Leonardo de Moura
ae2e00ae96 chore: update stage0 2020-08-17 06:29:24 -07:00
Leonardo de Moura
5d945dba2d test: match-expression 2020-08-16 15:50:22 -07:00
Leonardo de Moura
0064f7d2b9 chore: add let+patterns case
@Kha the patterns at `Binders.lean` for let-expressions are not matched correctly by
`match_syntax`. The problem is that we "reuse" kinds here:
```lean
def letIdDecl   : Parser := nodeWithAntiquot "letDecl" `Lean.Parser.Term.letDecl $ try (letIdLhs >> " := ") >> termParser
def letPatDecl  : Parser := node `Lean.Parser.Term.letDecl $ try (termParser >> pushNone >> optType >> " := ") >> termParser
def letEqnsDecl : Parser := node `Lean.Parser.Term.letDecl $ letIdLhs >> matchAlts false
def letDecl              := letIdDecl <|> letPatDecl <|> letEqnsDecl
```
This is a bad hack for implementing the `where` macro. I will remove it, and rewrite the code above as
```lean
def letIdDecl   := parser! try (letIdLhs >> " := ") >> termParser
def letPatDecl  := parser! try (termParser >> pushNone >> optType >> " := ") >> termParser
def letEqnsDecl := parser! letIdLhs >> matchAlts false
def letDecl     := parser! letIdDecl <|> letPatDecl <|> letEqnsDecl
```
Remark: we need the `letDecl` kind to be able to implement the `where`
macro.
I will do it tomorrow because it is a staging nightmare.
2020-08-16 15:41:53 -07:00
Leonardo de Moura
fdd8978bfe fix: structure instance in patterns
TODO: the structure instance `..` is not being handled correctly in
patterns. We must create new pattern variables for the missing fields.

Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2020-08-16 15:03:49 -07:00
Leonardo de Moura
bedb9d1fb6 fix: postponeElabTerm
This bug was introduced by the `ref`-plumbing refactoring.
2020-08-16 14:47:52 -07:00
Leonardo de Moura
7ea0d5394d feat: add withMacroExpansion 2020-08-16 14:28:07 -07:00
Leonardo de Moura
a97f8cb8e4 fix: nontermination at DepElim 2020-08-16 11:07:44 -07:00
Leonardo de Moura
8a7edf03ca feat: add commitWhenSome? 2020-08-16 10:55:15 -07:00
Leonardo de Moura
58f4b280ca feat: elaborate nomatch 2020-08-16 08:26:04 -07:00
Leonardo de Moura
655104d8df fix: use constructor transition when we have an empty set of alternatives 2020-08-16 08:25:38 -07:00
Leonardo de Moura
b616e8d07a test: do issue
This is the example triggered a panic message in the new frontend when
we were encoding `do a; b` as `a *> b`.
See 7cdf917c9
2020-08-15 16:07:01 -07:00
Leonardo de Moura
4f145c744e test: match-expr 2020-08-15 16:03:31 -07:00
Leonardo de Moura
e90efdcabf chore: update stage0 2020-08-15 15:59:30 -07:00
Leonardo de Moura
b03589757a chore: update stage0 2020-08-15 15:56:09 -07:00
Leonardo de Moura
7cdf917c97 fix: compiler do a; b as a >>= fun _ => b
Consider the following example
```lean
def div!: Nat → Nat → Nat
| x, 0 => panic! "division by zero"
| x, y => x/y

def weird (x : Nat) : MetaM Nat :=
unless (x > 0) (throwOther "x == 0") *>
let y := div! 10 x;
pure y
```
If we execute `weird 0`, it produces a "division by zero" panic
message.
This is a simple version of a much bigger function in the new
frontend.
This is not due to a bug in the compiler.
It produces the panic message because of the `do`-encoding
refactoring. Recall that, a few months ago,
we started to compile `do a; b` as `a *> b` (i.e., `seqRight a b`).
Thus, the example above is
`seqRight action1 (let y := div! 10 x; pure y)`
where `action1` is the `unless ...`.
In A-normal form, this is equivalent to

```lean
let y:= div! 10 x;
let action2 := pure y;
seqRight action1 action2
```
Thus, we execute `div! 10 x` before we even execute the `seqRight`.
This is counterintuitive and demonstrates once again how impure
features such as `panic!` are dangerous.

This commit reverts the `do`-encoding refactoring, and encodes
`do a; b` as `a >>= fun _ b` as we did in Lean3.

cc @Kha
2020-08-15 15:51:00 -07:00
Leonardo de Moura
e32ebc62c0 fix: tryPostponeIfMVar
Must not postpone if there is a term `t` (which is not a metavariable)
assigned to the metavariable `e.getAppFn`.
2020-08-15 14:36:16 -07:00
Leonardo de Moura
2295c315aa feat: add elabTermEnsuringType
This commit also fixes a match-expression error location issue.
2020-08-15 13:49:10 -07:00
Leonardo de Moura
e9748dd0f9 test: match equality proofs 2020-08-15 13:35:16 -07:00
Leonardo de Moura
bb261c51a6 fix: isDefEqQuick 2020-08-15 13:24:43 -07:00
Leonardo de Moura
34d9879061 test: add new tests 2020-08-15 13:14:16 -07:00
Leonardo de Moura
9a2f10c592 chore: update stage0 2020-08-15 08:20:12 -07:00
Leonardo de Moura
0be9516bd8 fix: instantiate metavariables in alternative local decls 2020-08-15 08:18:00 -07:00
Leonardo de Moura
63c4ee0acf chore: cleanup 2020-08-15 08:07:46 -07:00
Leonardo de Moura
7eed45dd45 fix: generalize isNatValueTransition 2020-08-15 07:59:31 -07:00
Leonardo de Moura
6e958d6208 refactor: cleanup 2020-08-15 07:55:44 -07:00
Leonardo de Moura
4223bdf8aa feat: add expandNatValuePattern 2020-08-15 07:26:22 -07:00
Leonardo de Moura
5d56cc5505 refactor: DepElim
We go back to the original approach where we pattern matching
alternative variables as `FVar`s.
We fix the original problem we had by implementing a simple
unification procedure for alternative `FVar`s.
2020-08-14 19:03:22 -07:00
Leonardo de Moura
87d506cb90 feat: instantiate metavariables in LocalDecls 2020-08-14 19:02:38 -07:00
Leonardo de Moura
00d46e4a7d chore: preparing to refactor DepElim 2020-08-14 19:02:20 -07:00
Leonardo de Moura
55d9689a7b fix: finalizePatternDecls 2020-08-14 13:55:43 -07:00
Leonardo de Moura
c5316d5cf3 fix: missing withMVarContext 2020-08-14 12:52:51 -07:00
Leonardo de Moura
50abd28f6e feat: generalize "constructor transition" 2020-08-14 12:38:43 -07:00
Leonardo de Moura
e2109ceab6 fix: missing substitution
We should include the `majorFVarId -> ctor-application` substitution
in each subgoal.
2020-08-14 12:38:00 -07:00
Leonardo de Moura
b3894200f0 feat: expose constructorApp? and isConstructorApp? 2020-08-14 12:37:34 -07:00
Leonardo de Moura
d85a41a4d7 chore: reduce number of dependencies
@Kha Please try to avoid importing `Lean.Meta`, it is huge, and any
change there was forcing a bunch of files to be recompiled since
`Parser.Extension` depends on `Parenthesizer`
2020-08-14 10:59:00 -07:00
Leonardo de Moura
8e81c19162 fix: combine "complete" and constructor transitions 2020-08-14 10:50:48 -07:00
Leonardo de Moura
b4b60dc326 feat: add List.filterMapM 2020-08-14 10:50:48 -07:00
Leonardo de Moura
bd8e2d305f feat: add Array.filterMap 2020-08-14 10:50:48 -07:00
Leonardo de Moura
54f6517ca3 fix: condition for using simple casesOn 2020-08-14 10:50:48 -07:00
Sebastian Ullrich
0df6445be6 fix: relax [builtinParenthesizer] check 2020-08-14 19:05:02 +02:00
Sebastian Ullrich
92162ffb7f feat: check parenthesizer attribute arguments 2020-08-14 19:05:02 +02:00
Sebastian Ullrich
72310a4aee fix: parenthesizer: ParserDescr.parsers should not be assumed to be a registered parser, or even one with a kind 2020-08-14 19:05:02 +02:00
Sebastian Ullrich
e9473722b1 feat: elaborate new quotation kinds, make macro_rules elaborator work with them 2020-08-14 17:44:29 +02:00
Sebastian Ullrich
e3cb897ab0 chore: update stage0 2020-08-14 17:19:05 +02:00
Sebastian Ullrich
129b60022d refactor: use distinct syntax kinds for quotations 2020-08-14 17:18:09 +02:00
Sebastian Ullrich
edeed7b849 chore: fix C++ warnings 2020-08-14 14:42:44 +02:00
Sebastian Ullrich
64631609cc feat: use [categoryParenthesizer] to parenthesize syntax parsers correctly 2020-08-14 14:42:44 +02:00
Sebastian Ullrich
3a28761e86 chore: make sure syntax parsers' names and kinds coincide 2020-08-14 14:33:51 +02:00
Sebastian Ullrich
52ddf5396f chore: restore marking stage0/ as binary files, which we lost at some point 2020-08-14 11:12:13 +02:00
Sebastian Ullrich
d66503f7a8 chore: update stage0 2020-08-14 11:03:35 +02:00