fix: prevent addPPExplicitToExposeDiff from assigning metavariables
#5276
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
toolchain-available
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Sep 6, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Sep 6, 2024
leanprover-community-bot
added
the
builds-mathlib
|
Mathlib CI status (docs):
|
nomeata
reviewed
Sep 12, 2024
| has type | ||
| OfNat.ofNat 0 = OfNat.ofNat 0 : Prop | ||
| ?_ (?_ ?_) = ?_ (?_ ?_) : Prop | ||
| but is expected to have type | ||
| OfNat.ofNat 0 = OfNat.ofNat 1 : Prop |
There was a problem hiding this comment.
Hmm, in this instance it’s not really an improvement. As a user I look at this and wonder why these metavariables couldn’t just be instantiated. But maybe this example is somewhat artificial.
Maybe add the test from the issue description to see one where it’s a UX improvement?
There was a problem hiding this comment.
Yeah, this one is a bit obscure. I've added some tests.
I tried making a version that is consistent about partially assigning metavariables to mimic a half-successful isDefEq, but I think in the end that's more confusing, since you don't know what the real type is. It might be nice having a real isDefEq diagnostic function instead.
Kha
added
awaiting-author
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 `withNewMCtxDepth` to prevent such assignments.
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, the reported type is now `?m.153 (?m.154 n2) = n2`.
…upport for over-applied functions
kmill
force-pushed
the
fix_addppexplicittoexposediff
branch
from
c94f8a3
to
d018246
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Type mismatch errors have a nice feature where expressions are annotated with
pp.explicitto expose differences viaisDefEqchecking. However, this procedure has side effects sinceisDefEqmay assign metavariables. This PR wraps the procedure withwithoutModifyingStateto 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:
With the change, it now says
has type ?m.153 (?m.154 n2) = n2.Note: this uses
withoutModifyingStateinstead ofwithNewMCtxDepthbecause we want to know something about whereisDefEqfailed — we are trying to simulate a very basic version ofisDefEqfor function applications, and we want the state at the point of failure to know which argument is "at fault".