Motivation: trace messages from systems such as instance synthesis or defeq checks can be massive and it is hard to find the relevant info within. We provide an interactive TraceExplorer component to do this.
@Kha This one required a bunch of manual fixes. The main issue is that
before we added the string interpolation feature, we created
`MessageData`s using `++` and coercions. For example, given
`(e : Expr)`, we would write
```
let msg : MessageData := "type: " ++ e
```
and rely on the coercions `String -> MessageData` and
`Expr -> MessageData`, and the instance `Append MessageData`.
However, heterogeneous operators "block" the expected type propagation downwards.
This kind of code is obsolete now since we can write a more compact
version using string interpolation
```
let msg := m!"type: {e}"
```
We need `MetaM` methods such as `isProp` to improve `ppGoal`.
This commit also moves `currNamespace` and `openDecls` to
`Core.Context`. Without this change, `Meta.ppExpr` was not taking
`open` commands into account.
@Kha I was tired of writing `arbitrary _` :)
There 0 places in the stdlib where the type needs to be provided.
If in the future we need to specify the type we can use
`arbitrary (α := <type>)`
@Kha Not sure whether we should have an option for supressing this
information or not.
We need this information for diagnosing problems. For example, I was trying to
understand why the elaborator was looping. I suspected it was the
TC module, but I was not getting any trace messages since the symbol
was overloaded, and the case that did not work was the expensive one :(
@Kha I am also tracking `currNamespace` and `openDecls`.
BTW, I also tried an experiment where I added `currNamespace` and
`openDecls` to `Meta.Context`, but it looked weird. This information
is only needed in the elaborator and pretty printer.
The `PPContext` object should contain everything you need. You
can put `currNamespace` and `openDecls` in the `Delaborator.Context`.
@Kha I am using `_shadowed.<idx>` suffix for marking variables that
have been shadowed. It is a bit verbose, but at least it is easy to
understand understand error messages such as
```
shadow.lean:4:0: error: type mismatch
h
has type
x._shadowed.1 = x._shadowed.1
but it is expected to have type
x = x
```
It is better than the old cryptic version
```
shadow.lean:4:0: error: type mismatch
h
has type
x = x
but it is expected to have type
x = x
```
