You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: grind? suggestions for goals with inaccessible hypothesis names (#14022)
This PR fixes `grind?` for goals containing hypotheses with inaccessible
names. Distinct terms that differ only in inaccessible variables have
identical anchors, so anchor references in generated tactic scripts
could resolve to the wrong term during replay, producing empty `grind
only` suggestions and scripts that could not close the goal. The `cases`
tactic now supports anchor ordinal references (e.g., `cases #a56e/2`
selects the second candidate matching the anchor), and `grind?` uses
them to disambiguate colliding anchors.
The fix consists of the following changes:
* Add anchor ordinal references to the `cases` tactic and use them in
generated scripts and `cases?` suggestions. The ordinal is resolved
against the case-split candidates that are ready to be split, skipping
resolved ones.
* Compute the anchor reference for a case-split from the candidate list
as it was before `selectNextSplit?` prunes it. The pruned list does not
contain the selected candidate, so ordinals computed from it did not
match the list inspected by the `cases` tactic during replay. This also
fixes a latent issue where the number of anchor digits did not account
for the candidate being split.
* Stop expanding the number of anchor digits when two terms have
identical 64-bit anchors. Expanding cannot disambiguate them, and it
produced confusing 16-digit references such as `#e48b8a1c9d724d48` that
were still ambiguous.
* Report an issue (in verbose mode) when a local theorem anchor collides
with a different local theorem. The collision is harmless for
`instantiate`: all matching theorems are instantiated during replay.
* Preserve parameters that mark types for case-splitting in the
suggestions. A parameter such as `[EqvGen]` both adds the constructors
as E-matching theorems and marks the type for case-splitting. The latter
has no script representation, so dropping the parameter made `cases`
steps on facts of these types fail when the suggestion was applied. The
script suggestion now carries these parameters: `grind [EqvGen] => ...`.
For the example in #13877, `grind?` now produces the same replayable
suggestions for both the inaccessible-name and the named version of the
goal:
```lean
grind [EqvGen] =>
instantiate only [= reflTransGen_iff_eq, EqvGen.rel]
instantiate only [#9242]
cases #14e8
· cases #d806 <;> cases #f38a <;> cases #e48b <;> instantiate only [#9242]
· instantiate only [= reflTransGen_iff_eq]
cases #d806
· cases #f38a <;> cases #5525 <;> instantiate only [#3442]
· cases #f38a
· cases #ae98/2
· instantiate only [#3442]
· cases #e48b <;> instantiate only [#9242]
· cases #ae98/2
· instantiate only [#3442]
· cases #e48b <;> instantiate only [#9242]
```
Closes#13877.
**Note**: Distinct local theorems may have the same anchor (e.g., they differ only in
105
+
inaccessible variables). This is not an error: when replaying the generated tactic,
106
+
all matching theorems are instantiated. We just report an issue flagging the collision.
107
+
-/
108
+
if entries.any fun entry => entry.anchor == anchor && entry.e != type then
109
+
reportIssue! "anchor `#{anchorToString numDigits anchor}` is ambiguous, distinct local theorems have the same anchor{indentExpr type}\nall of them are instantiated by the generated `instantiate` tactic"
101
110
let param ← `(Parser.Tactic.Grind.thm| $(← mkAnchorSyntax numDigits anchor):anchor)
0 commit comments