lean4-htt/tests/lean/run/4405.lean
Kyle Miller 28cf146d00
fix: make sure monad lift coercion elaborator has no side effects (#6024)
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.
2024-11-13 16:22:31 +00:00

56 lines
1.2 KiB
Text

import Lean.Elab.Command
set_option pp.mvars false
/--
error: application type mismatch
⟨Nat.lt_irrefl (?_ n), Fin.is_lt ?_⟩
argument
Fin.is_lt ?_
has type
↑?_ < ?_ : Prop
but is expected to have type
?_ n < ?_ n : Prop
-/
#guard_msgs in
def foo := fun n => (not_and_self_iff _).mp ⟨Nat.lt_irrefl _, Fin.is_lt _⟩
/--
error: type mismatch
Fin.is_lt ?_
has type
↑?_ < ?_ : Prop
but is expected to have type
?_ < ?_ : Prop
---
error: unsolved goals
case a
⊢ Nat
this : ?_ < ?_
⊢ True
-/
#guard_msgs in
def test : True := by
have : ((?a : Nat) < ?a : Prop) := by
refine Fin.is_lt ?_
done
done
open Lean Meta
/--
info: Defeq?: false
---
info: fun x_0 x_1 => x_1
-/
#guard_msgs in
run_meta do
let mvarIdNat ← mkFreshExprMVar (.some (.const ``Nat []))
let mvarIdFin ← mkFreshExprMVar (.some (.app (.const `Fin []) mvarIdNat))
-- mvarIdNat.assign (.app (.const ``Fin.val []) mvaridFin))
let b ← isDefEq mvarIdNat (mkApp2 (.const ``Fin.val []) mvarIdNat mvarIdFin)
logInfo m!"Defeq?: {b}" -- prints true
-- Now mvaridNat occurs in its own type
-- This will stack overflow
let r ← abstractMVars mvarIdFin (levels := false)
logInfo m!"{r.expr}"