Repository navigation
fix: fun_cases when a goal variable depends on a match discriminant - #15737
Merged
Merged
Conversation
Contributor
Author
|
!bench |
|
Benchmark results for 87980ca against 8853987 are in. There are significant results. @sgraf812
Medium changes (2🟥)
Small changes (1✅, 36🟥)
|
Contributor
Author
|
!bench |
sgraf812
force-pushed
the
sg/fun-cases-index-match
branch
from
October 19, 2026 13:37
0352305 to
44bed7e
Compare
Contributor
Author
|
!bench |
sgraf812
force-pushed
the
sg/fun-cases-index-match
branch
from
October 19, 2026 13:41
44bed7e to
c45c172
Compare
Contributor
Author
|
!bench |
When the functional induction construction splits a `match`, it abstracts the discriminants from the goal to form the new motive. If another free variable in the goal has a type that mentions a discriminant, the abstraction is type-incorrect. Example: `match (generalizing := false) w` inside an alternative that binds `x : Fin w.ctorIdx`. For the motive of a `match`, `mkLambdaFVarsMasked` now keeps such a discriminant unabstracted (`checkTypeCorrect := true`). It checks the abstraction over all discriminants once, and only if that check fails does it check each discriminant. The equality `w = pattern` that `MatcherApp.transform` adds lets `rwMatcher` reduce the match in each alternative. The abstraction of the parameters of the principles checks nothing.
Contributor
Author
|
!bench |
sgraf812
force-pushed
the
sg/fun-cases-index-match
branch
from
October 19, 2026 13:45
c45c172 to
a82fd40
Compare
|
Failed to find a commit to compare against. You can edit the original message until the command succeeds. |
Contributor
Author
|
!bench |
|
Benchmark results for a82fd40 against 8853987 are in. No significant results found. @sgraf812
Small changes (1✅, 6🟥)
|
nomeata
approved these changes
Oct 19, 2026
sgraf812
marked this pull request as ready for review
October 20, 2026 13:49
sgraf812
enabled auto-merge
October 20, 2026 13:49
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
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
fun_casesandfun_inductionfor amatchwhose discriminant appears in the type of another variable in the goal.Example:
The functional cases construction splits the inner match with a motive that abstracts the discriminant
wfrom the goalmotive (Op.y x) (match w with ...). The variablex : Fin w.ctorIdxstays free, sofun w' => motive (Op.y x) ...is type-incorrect.For the motive of a
match,mkLambdaFVarsMaskednow abstracts a discriminant only if the result is type-correct (checkTypeCorrect := true). It checks the abstraction over all discriminants once, and only if that check fails does it check each discriminant. An unabstracted discriminant still gets the equalityw = patternfromMatcherApp.transform, andrwMatcheruses this equality to reduce the match in each alternative. The defaultmatchwas not affected, because it generalizesxtogether withw.Closes #8213