-
Notifications
You must be signed in to change notification settings - Fork 619
fix: use withFreshZetaDeltaFVarIds
to avoid leaking zetaDeltaFVarIds
between different simp
calls
#7539
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
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
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):
|
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
Labels
builds-mathlib
CI has verified that Mathlib builds against this PR
changelog-language
Language features, tactics, and metaprograms
P-low
We are not planning to work on this issue
toolchain-available
A toolchain is available for this PR, at leanprover/lean4-pr-releases:pr-release-NNNN
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 othersimp
calls.The idea is: when tracking
zetaDeltaFVarIds
, then we settrackZetaDelta := true
andzetaDeltaFVarIds := {}
, and at the end we restorezetaDeltaFVarIds
to the value it had originally. If this is nested inside another such tracking, we add the newzetaDeltaFVarIds
to the original set.Closes #6655