fix: give call-site vcgen [f] arguments the explicit-spec priority#14528
Merged
Conversation
github-actions
Bot
added
the
toolchain-available
|
Mathlib CI status (docs):
|
Collaborator
|
Reference manual CI status:
|
sgraf812
force-pushed
the
sg/vcgen-callsite-unfold-prio
branch
2 times, most recently
from
July 24, 2026 08:12
437f23b to
18b6923
Compare
sgraf812
changed the title
vcgen [f] unfoldings the explicit-spec priorityvcgen [f] arguments the explicit-spec priority
This PR makes every `vcgen [f]` argument enter the spec database at the call-site priority band, so a definition to unfold or a spec supplied as a term outranks an ambient `@[spec]` on the same program. Two paths dropped the band and inserted at the default priority: the equational and unfold specs `addSimpSpecs` derives from a call's simp-style arguments, and a spec supplied as a compound term (`vcgen [show … from h]`, `[f x]`) through `mkSpecTheoremFromStx`. Both now use `explicitSpecPrio`, the band a bracketed identifier already receives, so a bracketed definition's unfolding and a term spec both outrank a plain `@[spec]` or `@[spec high]` keyed on the same program, including when the program's state type is a variable and the entries share a discrimination-tree key.
sgraf812
force-pushed
the
sg/vcgen-callsite-unfold-prio
branch
from
July 24, 2026 08:21
18b6923 to
14878dd
Compare
sgraf812
enabled auto-merge
July 24, 2026 08:28
Rob23oba
pushed a commit
to Rob23oba/lean4
that referenced
this pull request
Jul 24, 2026
…anprover#14535) This PR fixes `vcgen [f, h, …]` reporting `No spec found` for a sibling call inside a self-recursive `f` when the list both brackets `f` to unfold and supplies a spec `h` for `f`, whether `h` is named or pulled by `*`. A bracketed definition's unfoldings now rank below both a named spec and a `*` hypothesis for the same program, so at a recursive call `vcgen` applies that spec and stops rather than unfolding `f` again into a branch whose sibling call has no matching spec. The regression came from leanprover#14528, which had raised these unfoldings to the named-spec priority.
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
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 makes every
vcgen [f]argument enter the spec database at the call-site priority band, so a definition to unfold or a spec supplied as a term outranks an ambient@[spec]on the same program.Two paths dropped the band and inserted at the default priority: the equational and unfold specs
addSimpSpecsderives from a call's simp-style arguments, and a spec supplied as a compound term (vcgen [show … from h],[f x]) throughmkSpecTheoremFromStx. Both now useexplicitSpecPrio, the band a bracketed identifier already receives, so a bracketed definition's unfolding and a term spec both outrank a plain@[spec]or@[spec high]keyed on the same program, including when the program's state type is a variable and the entries share a discrimination-tree key.