Type mismatch errors have a nice feature where expressions are annotated
with `pp.explicit` to expose differences via `isDefEq` checking.
However, this procedure has side effects since `isDefEq` may assign
metavariables. This PR wraps the procedure with `withoutModifyingState`
to prevent assignments from escaping.
Assignments can lead to confusing behavior. For example, in the
following a higher-order unification fails, but the difference-finding
procedure unifies metavariables in a naive way, producing a baffling
error message:
```lean
theorem test {f g : Nat → Nat} (n : Nat) (hfg : ∀a, f (g a) = a) :
f (g n) = n := hfg n
example {g2 : ℕ → ℕ} (n2 : ℕ) : (λx => x * 2) (g2 n2) = n2 := by
with_reducible refine test n2 ?_
/-
type mismatch
test n2 ?m.648
has type
(fun x ↦ x * 2) (g2 n2) = n2 : Prop
but is expected to have type
(fun x ↦ x * 2) (g2 n2) = n2 : Prop
-/
```
With the change, it now says `has type ?m.153 (?m.154 n2) = n2`.
Note: this uses `withoutModifyingState` instead of `withNewMCtxDepth`
because we want to know something about where `isDefEq` failed — we are
trying to simulate a very basic version of `isDefEq` for function
applications, and we want the state at the point of failure to know
which argument is "at fault".
16 lines
506 B
Text
16 lines
506 B
Text
1870.lean:12:2-12:35: error: type mismatch
|
|
congrArg ?_ (congrArg ?_ ?_)
|
|
has type
|
|
?_ (?_ ?_) = ?_ (?_ ?_) : Prop
|
|
but is expected to have type
|
|
OfNat.ofNat 0 = OfNat.ofNat 1 : Prop
|
|
1870.lean:16:2-16:16: error: tactic 'apply' failed, failed to unify
|
|
?f ?a₁ = ?f ?a₂
|
|
with
|
|
OfNat.ofNat 0 = OfNat.ofNat 1
|
|
⊢ OfNat.ofNat 0 = OfNat.ofNat 1
|
|
1870.lean:21:2-21:16: error: tactic 'apply' failed, failed to unify
|
|
?f ?a₁ = ?f ?a₂
|
|
with
|
|
OfNat.ofNat 0 = OfNat.ofNat 1
|
|
⊢ OfNat.ofNat 0 = OfNat.ofNat 1
|