This PR improves the “expected type mismatch” error message by omitting the type's types when they are defeq, and putting them into separate lines when not. I found it rather tediuos to parse the error message when the expected type is long, because I had to find the `:` in the middle of a large expression somewhere. Also, when both are of sort `Prop` or `Type` it doesn't add much value to print the sort (and it’s only one hover away anyways).
27 lines
1,022 B
Text
27 lines
1,022 B
Text
mulcommErrorMessage.lean:8:13-13:25: error: type mismatch
|
|
fun a b => ?m
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝
|
|
the following variables have been introduced by the implicit lambda feature
|
|
a✝ : Bool
|
|
b✝ : Bool
|
|
you can disable implicit lambdas using `@` or writing a lambda expression with `{}` or `[]` binder annotations.
|
|
mulcommErrorMessage.lean:12:22-12:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
?m = ?m
|
|
but is expected to have type
|
|
false = true
|
|
mulcommErrorMessage.lean:16:3-17:47: error: type mismatch
|
|
fun a b => ?m
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝
|
|
the following variables have been introduced by the implicit lambda feature
|
|
a✝ : Bool
|
|
b✝ : Bool
|
|
you can disable implicit lambdas using `@` or writing a lambda expression with `{}` or `[]` binder annotations.
|
|
mulcommErrorMessage.lean:16:12-17:47: error: failed to elaborate eliminator, expected type is not available
|