`generalize ... at *` sometimes will try to modify the recursive hypothesis corresponding to the current theorem being defined, which may not be the expected behaviour. It should only try to `generalize` hypotheses that it can actually modify and are visible, not implementation details. Otherwise this means that there are discrepancies between `generalize ... at *` and `generalize ... at H`, even though `H` is the only hypothesis in the context. This commit uses `getLocalHyps` instead of `getFVarIds` to get the current valid `FVarIds` in the context. This uses `isImplementationDetail` to filter out `FVarIds` that are implementation details in the context and are not visible to the user and should not be manipulated by `generalize`. Closes #4845
12 lines
313 B
Text
12 lines
313 B
Text
/-!
|
|
Generalize should not try to abstract the variable from hypotheses that are
|
|
implementation details. -/
|
|
|
|
/-!
|
|
In this case, generalize tries to revert the lemma being defined to generalize
|
|
the 0 in it. -/
|
|
|
|
example : 0 = 0 → True := by
|
|
intro H; generalize _H : 0 = z at *
|
|
trace_state
|
|
constructor
|