@Kha we do that in Lean 3. It helps when the error is due to incorrect universe levels.
BTW, I had to update `tests/lean/server/content_diag.json` since the
error message is different, but a few other stuff changed too.
Could you please take a look whether the test is still correct?
@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
```
@Kha, we now support variable/constant shadowing in patterns.
A constant may occur in a pattern if it is a constructor or tagged with
the new [pattern] attribute. In the standard library, I have tagged
'add', 'zero', 'one', 'bit0', 'bit1' and 'rfl' with this new attribute.
BTW, arbitrary constants and variables may occur nested in type ascriptions and
inaccessible terms.
Here is an example:
meta_definition tactic_result_to_string {A : Type} : tactic_result A → string
| (success a s) := to_string a
| (exception ⌞A⌟ e s) := "Exception: " ++ to_string (e ())
I had to use the inaccessible ⌞A⌟ in the example above, otherwise, we would be shadowing the parameter
{A : Type}, and we would get a type error.
The new validation is performed at to_pattern_fn (parser.cpp).
