Function applications `(f ...)` were not being elaborated correctly when
`f` has implicit parameters occurring after auto_params.
The new test exposes the problem.
This bug was found when developing the red black tree module.
This commit also fixes the following bugs:
- Invoke type class resolution again after tactic execution at
synthesize method. Reason: metavariables occurring in type
class instances may have been synthesized by tactics.
- mctx.assign optimization at invoke_tactic was incorrect
when the metavariable was assigned by typing rules.
We use the auxiliary procedure pull_nested_rec_fn to pull recursive
application in nested match expressions. This is needed because the
nested match expression is compiled before we process the recursive
procedure that contains it. This transformation may produce
performance problems if the recursive application does not depend on
the data being matched. Here is an example from the new test:
```
def tst : tree → nat
| (tree.leaf v) := v
| (tree.node v l r) :=
match f v with
| tt := tst l
| ff := tst r
end
```
pull_nested_rec_fn will convert it into
```
def tst : tree → nat
| (tree.leaf v) := v
| (tree.node v l r) := tst._match_1 (f v) (tst l) (tst r)
```
Since our interpreter uses eager evaluation, both `(tst l)` and `(tst r)`
are executed. This commit fixes this issue by expanding `tst._match_1`
during code generation.
TODO: we are not checking if the unicode escape values provide by the
user correspond to valud unicode scalar values. We should check how
other languanges handle this case.
Comment from parser.h
This commit makes sure that all declaration parameters must be surrounded with some kind of bracket. (e.g., '()', '{}', '[]').
The goal is to avoid counter-intuitive declarations such as:
example p : false := trivial
def main proof : false := trivial
which would be parsed as
example (p : false) : _ := trivial
def main (proof : false) : _ := trivial
where `_` in both cases is elaborated into `true`. This issue was raised by @gebner in the slack channel.
Remark: we still want implicit delimiters for lambda/pi expressions. That is, we want to write
fun x : t, s
or
fun x, s
instead of
fun (x : t), s
As described at issue #1760, the new error message is:
```
1760.lean:6:18: error: type mismatch at application
f x
term
x
has type
big_type : Type 1
but is expected to have type
?m_1 : Type
```
To make the equation compiler more convenient to use, we will add a
couple of preprocessing steps.
This commit adds the first one of them. In this step, we use
type inference to refine pattern variables, and we relax the
restrictions on inaccessible annotations.
We will also add a preprocessing step that implements the "complete
transition" step before we execute the elim_match step.
