fix: use withFreshZetaDeltaFVarIds to avoid leaking zetaDeltaFVarIds between different simp calls
#7539
Conversation
This file contains hidden or 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
…ds` between different `simp` calls
github-actions
bot
added
the
toolchain-available
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Mar 18, 2025
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Mar 18, 2025
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Mar 18, 2025
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Mar 18, 2025
|
Mathlib CI status (docs):
|
leanprover-community-bot
added
breaks-mathlib
nomeata
added
the
changelog-language
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 13, 2025
This PR fixes a bug in `simp` where it was not resetting the set of zeta-delta reduced let definitions between `simp` calls. It also fixes a bug where `simp` would report zeta-delta reduced let definitions that weren't given as simp arguments (these extraneous let definitions appear due to certain processes temporarily setting `zetaDelta := true`). This PR also modifies the metaprogramming interface for the zeta-delta tracking functions to be re-entrant and to prevent this kind of no-reset bug from occurring again. Closes #6655. Re-entrance of this metaprogramming interface is not needed to fix #6655, but it is needed for some future PRs. The `tests/lean/run/6655.lean` file has an example of a deficiency of `simp?`, where `simp?` still over-reports unfolded let declarations. This is likely due to `withInferTypeConfig` setting `zetaDelta := true` from within `isDefEq`, but I did not verify this. This PR supersedes #7539. The difference is that this PR has `withResetZetaDeltaFVarIds` save and restore `zetaDeltaFVarIds`, but that PR saves and then extends `zetaDeltaFVarIds` to persist unfolded fvars. The behavior in this PR lets metaprograms control whether they want to persist any of the unfolded fvars in this context themselves. In practice, metaprograms that use `withResetZetaDeltaFVarIds` are creating many temporary fvars and are doing dependence computations. These temporary fvars shouldn't be persisted, and also dependence shouldn't be inferred from the fact that a dependence calculation was done. (Concrete example: the let-to-have transformation in an upcoming PR can be run from within simp. Just because let-to-have unfolds an fvar while calculating dependencies of lets doesn't mean that this fvar should be included by `simp?`.)
algebraic-dev
pushed a commit
to algebraic-dev/lean4
that referenced
this pull request
Jun 18, 2025
…8753) This PR fixes a bug in `simp` where it was not resetting the set of zeta-delta reduced let definitions between `simp` calls. It also fixes a bug where `simp` would report zeta-delta reduced let definitions that weren't given as simp arguments (these extraneous let definitions appear due to certain processes temporarily setting `zetaDelta := true`). This PR also modifies the metaprogramming interface for the zeta-delta tracking functions to be re-entrant and to prevent this kind of no-reset bug from occurring again. Closes leanprover#6655. Re-entrance of this metaprogramming interface is not needed to fix leanprover#6655, but it is needed for some future PRs. The `tests/lean/run/6655.lean` file has an example of a deficiency of `simp?`, where `simp?` still over-reports unfolded let declarations. This is likely due to `withInferTypeConfig` setting `zetaDelta := true` from within `isDefEq`, but I did not verify this. This PR supersedes leanprover#7539. The difference is that this PR has `withResetZetaDeltaFVarIds` save and restore `zetaDeltaFVarIds`, but that PR saves and then extends `zetaDeltaFVarIds` to persist unfolded fvars. The behavior in this PR lets metaprograms control whether they want to persist any of the unfolded fvars in this context themselves. In practice, metaprograms that use `withResetZetaDeltaFVarIds` are creating many temporary fvars and are doing dependence computations. These temporary fvars shouldn't be persisted, and also dependence shouldn't be inferred from the fact that a dependence calculation was done. (Concrete example: the let-to-have transformation in an upcoming PR can be run from within simp. Just because let-to-have unfolds an fvar while calculating dependencies of lets doesn't mean that this fvar should be included by `simp?`.)
wkrozowski
pushed a commit
to wkrozowski/lean4
that referenced
this pull request
Jun 24, 2025
…8753) This PR fixes a bug in `simp` where it was not resetting the set of zeta-delta reduced let definitions between `simp` calls. It also fixes a bug where `simp` would report zeta-delta reduced let definitions that weren't given as simp arguments (these extraneous let definitions appear due to certain processes temporarily setting `zetaDelta := true`). This PR also modifies the metaprogramming interface for the zeta-delta tracking functions to be re-entrant and to prevent this kind of no-reset bug from occurring again. Closes leanprover#6655. Re-entrance of this metaprogramming interface is not needed to fix leanprover#6655, but it is needed for some future PRs. The `tests/lean/run/6655.lean` file has an example of a deficiency of `simp?`, where `simp?` still over-reports unfolded let declarations. This is likely due to `withInferTypeConfig` setting `zetaDelta := true` from within `isDefEq`, but I did not verify this. This PR supersedes leanprover#7539. The difference is that this PR has `withResetZetaDeltaFVarIds` save and restore `zetaDeltaFVarIds`, but that PR saves and then extends `zetaDeltaFVarIds` to persist unfolded fvars. The behavior in this PR lets metaprograms control whether they want to persist any of the unfolded fvars in this context themselves. In practice, metaprograms that use `withResetZetaDeltaFVarIds` are creating many temporary fvars and are doing dependence computations. These temporary fvars shouldn't be persisted, and also dependence shouldn't be inferred from the fact that a dependence calculation was done. (Concrete example: the let-to-have transformation in an upcoming PR can be run from within simp. Just because let-to-have unfolds an fvar while calculating dependencies of lets doesn't mean that this fvar should be included by `simp?`.)
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.
This PR fixes the tracking of let variables used in
simp?. It used to return too many let variables if these let variables were used in othersimpcalls.The idea is: when tracking
zetaDeltaFVarIds, then we settrackZetaDelta := trueandzetaDeltaFVarIds := {}, and at the end we restorezetaDeltaFVarIdsto the value it had originally. If this is nested inside another such tracking, we add the newzetaDeltaFVarIdsto the original set.Closes #6655