feat: incremental elaboration of definition headers, bodies, and tactics #3940
Conversation
This file contains 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
|
#3636 was accidentally closed without merging |
github-actions
bot
added
the
toolchain-available
|
Mathlib CI status (docs):
|
tydeu
reviewed
Apr 18, 2024
Kha
force-pushed
the
incr-tactic
branch
3 times, most recently
from
285aef6
to
a50a2d0
Compare
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Apr 20, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Apr 20, 2024
leanprover-community-mathlib4-bot
added
the
breaks-mathlib
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Apr 20, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Apr 20, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
Apr 20, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/mathlib4
that referenced
this pull request
Apr 20, 2024
…level tactic blocks
Use that to move `HeadersParsedSnapshot` downstream
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
May 11, 2024
apnelson1
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
May 12, 2024
Backward-compatible fixes for leanprover/lean4#3940. In particular, gets rid of two `open private` (out of six in all of Mathlib) which in my opinion really were not necessary and just invited breakage. Somehow the unused variables and unnecessary `have` linters became *more* complete, which might be due to earlier mvar instantiation in `Elab.MutualDef` but I haven't investigated deeply.
callesonne
pushed a commit
to leanprover-community/mathlib4
that referenced
this pull request
May 16, 2024
Backward-compatible fixes for leanprover/lean4#3940. In particular, gets rid of two `open private` (out of six in all of Mathlib) which in my opinion really were not necessary and just invited breakage. Somehow the unused variables and unnecessary `have` linters became *more* complete, which might be due to earlier mvar instantiation in `Elab.MutualDef` but I haven't investigated deeply.
semorrison
force-pushed
the
releases/v4.8.0
branch
from
c59a24a
to
69965c2
Compare
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
May 22, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
May 22, 2024
leanprover-community-mathlib4-bot
added a commit
to leanprover-community/batteries
that referenced
this pull request
May 22, 2024
JovanGerb
pushed a commit
to JovanGerb/lean4
that referenced
this pull request
May 22, 2024
…ics (leanprover#3940) Extends Lean's incremental reporting and reuse between commands into various steps inside declarations: * headers and bodies of each (mutual) definition/theorem * `theorem ... := by` for each contained tactic step, including recursively inside supported combinators currently consisting of * `·` (cdot), `case`, `next` * `induction`, `cases` * macros such as `next` unfolding to the above  *Incremental reuse* means not recomputing any such steps if they are not affected by a document change. *Incremental reporting* includes the parts seen in the recording above: the progress bar and messages. Other language server features such as hover etc. are *not yet* supported incrementally, i.e. they are shown only when the declaration has been fully processed as before. --------- Co-authored-by: Scott Morrison <[email protected]>
github-merge-queue bot
pushed a commit
that referenced
this pull request
Jun 27, 2024
…es (#4569) This appears to have been a semantic merge conflict between #3940 and #4129. The effect on the language server is that if two edits are sufficiently close in time to create an interrupt, some elaboration steps like `simp` may accidentally catch the exception when it is triggered during their execution, which makes incrementality assume that elaboration of the body was successful, which can lead to incorrect reuse, presenting the interrupted state to the user with symptoms such as "uses sorry" without accompanying errors and incorrect lints.
github-actions bot
pushed a commit
that referenced
this pull request
Jun 27, 2024
…es (#4569) This appears to have been a semantic merge conflict between #3940 and #4129. The effect on the language server is that if two edits are sufficiently close in time to create an interrupt, some elaboration steps like `simp` may accidentally catch the exception when it is triggered during their execution, which makes incrementality assume that elaboration of the body was successful, which can lead to incorrect reuse, presenting the interrupted state to the user with symptoms such as "uses sorry" without accompanying errors and incorrect lints. (cherry picked from commit f3cb8a6)
semorrison
pushed a commit
that referenced
this pull request
Jun 28, 2024
…es (#4569) This appears to have been a semantic merge conflict between #3940 and #4129. The effect on the language server is that if two edits are sufficiently close in time to create an interrupt, some elaboration steps like `simp` may accidentally catch the exception when it is triggered during their execution, which makes incrementality assume that elaboration of the body was successful, which can lead to incorrect reuse, presenting the interrupted state to the user with symptoms such as "uses sorry" without accompanying errors and incorrect lints. (cherry picked from commit f3cb8a6)
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.
Extends Lean's incremental reporting and reuse between commands into various steps inside declarations:
theorem ... := byfor each contained tactic step, including recursively inside supported combinators currently consisting of·(cdot),case,nextinduction,casesnextunfolding to the aboveIncremental reuse means not recomputing any such steps if they are not affected by a document change. Incremental reporting includes the parts seen in the recording above: the progress bar and messages. Other language server features such as hover etc. are not yet supported incrementally, i.e. they are shown only when the declaration has been fully processed as before.