28cf146d00
This PR fixes a bug where the monad lift coercion elaborator would partially unify expressions even if they were not monads. This could be taken advantage of to propagate information that could help elaboration make progress, for example the first `change` worked because the monad lift coercion elaborator was unifying `@Eq _ _` with `@Eq (Nat × Nat) p`: ```lean example (p : Nat × Nat) : p = p := by change _ = ⟨_, _⟩ -- used to work (yielding `p = (p.fst, p.snd)`), now it doesn't change ⟨_, _⟩ = _ -- never worked ``` As such, this is a breaking change; you may need to adjust expressions to include additional implicit arguments.
27 lines
1.1 KiB
Text
27 lines
1.1 KiB
Text
mulcommErrorMessage.lean:8:13-13:25: error: type mismatch
|
|
fun a b => ?m
|
|
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:12:22-12:25: error: type mismatch
|
|
rfl
|
|
has type
|
|
?m = ?m : Prop
|
|
but is expected to have type
|
|
false = true : Prop
|
|
mulcommErrorMessage.lean:16:3-17:47: error: type mismatch
|
|
fun a b => ?m
|
|
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
|