It had two problems:
- It was preventing coercions from being applied.
- It was compromising error recovery. The body of the lambda was not
being elaborated when the exception was thrown.
The new error message is more verbose and potentially confusing, but
it is better than the one produced this morning.
We should never assume a `Syntax` node has a specific number of
children because the parser error recovery may produce partial
abstract syntax trees. We should use `stx[i]` instead because
`Syntax.getOp` returns `Syntax.missing` when `i` is out of bounds.
@Kha I marked the corresponding methods as `protected`.
I currently can't stand `throw_error`, and I am optimistic about
server highlighting feature you are working on :)
@Vtec234 I am storing the binder information using `TermInfo`.
If it helps, I can add a custom `Info` constructor.
Example: `| Info.ofBinderInfo (i : BinderInfo)`.
closes#191
@Kha Note that it expands into a "let rec".
There are many other places where an optional `where`-clause is
useful. We can add them later. It is relatively easy to add support in
other places using the new helper functions
`expandWhereDeclsOpt` and `expandMatchAltsWhereDecls`
Before this commit, each `isDefEq u v` invocation would fail if there
were pending universe level constraints. This commit, moves the
postponed universe constraints back to the `MetaM` state.
It also adds the combinator
```lean
withoutPostponingUniverseConstraints x
```
which executes `x` and throws an error if there are pending universe
constraints. We use the combinator at `elabApp` and `elabBinders`.
Without this commit, we would fail to elaborate simple terms such as
```lean
Functor.map Prod.fst (x s)
```
because after elaborating `Prod.fst` and trying to ensure its type
match the expected one, we would be stuck at the universe constraint:
```
u =?= max u ?v
```
Another benefit of the new approach is better error messages. Instead
of getting a mysterious type mismatch constraint, we get a list of
universe contraints the system is stuck at.
cc @Kha