fix: refine how simp tracks unfolded local definitions
#8753
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
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 so that they are re-entrant and prevent this kind of no-reset bug from occurring again. Closes leanprover#6655. Re-entrance of this metaprogramming interface is not need 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.
github-actions
bot
added
the
toolchain-available
Collaborator
|
Mathlib CI status (docs):
|
3 tasks
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Jun 13, 2025
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Jun 13, 2025
leanprover-community-bot
added
the
builds-mathlib
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
2 participants
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 a bug in
simpwhere it was not resetting the set of zeta-delta reduced let definitions betweensimpcalls. It also fixes a bug wheresimpwould report zeta-delta reduced let definitions that weren't given as simp arguments (these extraneous let definitions appear due to certain processes temporarily settingzetaDelta := 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.leanfile has an example of a deficiency ofsimp?, wheresimp?still over-reports unfolded let declarations. This is likely due towithInferTypeConfigsettingzetaDelta := truefrom withinisDefEq, but I did not verify this.This PR supersedes #7539. The difference is that this PR has
withResetZetaDeltaFVarIdssave and restorezetaDeltaFVarIds, but that PR saves and then extendszetaDeltaFVarIdsto 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 usewithResetZetaDeltaFVarIdsare 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 bysimp?.)