3acd77a154
Floris van Doorn [reported on Zulip](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/have.20tactic.20error.20recovery/near/425283053) that it is confusing that the `have : T := e` tactic completely fails if the body `e` is not of type `T`. This is in contrast to `have : T := by exact e`, which does not completely fail when `e` is not of type `T`. This ends up being caused by `elabTermEnsuringType` throwing an error when it fails to insert a coercion. Now, it detects this case, and it checks the `errToSorry` flag to decide whether to throw the error or to log the error and insert a `sorry`. This is justified by `elabTermEnsuringType` being a frontend to `elabTerm`, which inserts `sorry` on error. An alternative would be to make `ensureType` respect `errToSorry`, but there exists code that expects being able to catch when `ensureType` fails. Making such code manipulate `errToSorry` seems error prone, and this function is not a main entry point to the term elaborator, unlike `elabTermEnsuringType`.
33 lines
1.2 KiB
Text
33 lines
1.2 KiB
Text
mulcommErrorMessage.lean:8:13-13:25: error: type mismatch
|
|
fun a b => ?m a b
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b : Sort (imax ?u ?u ?u)
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝ : Prop
|
|
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:11:22-11:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
true = true : Prop
|
|
but is expected to have type
|
|
true = false : Prop
|
|
mulcommErrorMessage.lean:12:22-12:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
false = false : Prop
|
|
but is expected to have type
|
|
false = true : Prop
|
|
mulcommErrorMessage.lean:16:3-17:47: error: type mismatch
|
|
fun a b => ?m a b
|
|
has type
|
|
(a : ?m) → (b : ?m a) → ?m a b : Sort (imax ?u ?u ?u)
|
|
but is expected to have type
|
|
a✝ * b✝ = b✝ * a✝ : Prop
|
|
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
|