feat: Compute matching patterns for automatic induction #5835
Conversation
# Conflicts: # Source/DafnyCore/Verifier/Statements/BoogieGenerator.TrForallStmt.cs
# Conflicts: # Source/DafnyCore/Verifier/BoogieGenerator.Methods.cs # Source/DafnyCore/Verifier/Statements/BoogieGenerator.TrForallStmt.cs
| (ToNatRight([]) * BASE() + First(xs1)) * BASE() + First(xs); | ||
| { reveal ToNatRight(); } | ||
| (0 * BASE() + First(xs1)) * BASE() + First(xs); | ||
| } |
There was a problem hiding this comment.
Why isn't the right proof here to rewrite xs as [xs[0], xs[1]]?
There was a problem hiding this comment.
I don't see how that rewrite helps any. It's nice to have a name for the expression [xs[1]]. But I removed the assertion assert DropFirst(xs1) == [];, which wasn't needed.
docs/dev/news/5835.feat
Outdated
| @@ -0,0 +1,5 @@ | |||
| Fill in matching patterns for the quantifiers introduced by automatic induction to represent the induction hypothesis. Suppress the generation of the induction hypothesis if no such matching patterns are found. Enhance tooltips accordingly. This feature is added to make stabilize verification, but by sometimes not generating induction hypotheses, some automatic proofs may no longer go through. | |||
There was a problem hiding this comment.
Typo: "is added to make stabilize verification"
Shouldn't we include an example or two?
Source/IntegrationTests/TestFiles/LitTests/LitTest/dafny3/Abstemious.dfy
Show resolved
Hide resolved
| let-expressions.dfy(8,8): Info: Selected triggers: {s[_t#0], s[i]} | ||
| let-expressions.dfy(9,8): Info: Selected triggers: {s[_t#0], s[i]} | ||
| let-expressions.dfy(8,8): Info: Selected triggers: {s[_t#0], s[i]} where _t#0 := i + 1 | ||
| let-expressions.dfy(9,8): Info: Selected triggers: {s[_t#0], s[i]} where _t#0 := i + 1 |
There was a problem hiding this comment.
These temporary variable names appeared when we started supporting automatic rewriting of matching loops, but the trigger that we add is (almost?) always the same for this new variable as it was for the original variable that it looped with (after all, it was precisely because the new term caused a loop with the trigger of the first one that we created a new variable).
Given this, shouldn't we just hide that redundant trigger and print only {s[i]}, rather that showing the temporary variable with the additional where clause?
There was a problem hiding this comment.
We used to print something like
loop-detection-messages--unit-tests.dfy(12,9): Warning: Selected triggers: {f(i)} (may loop with "f(i + 1)")
/!\ Suppressing loops would leave this expression without triggers.
Once these loops were eliminated by rewriting we returned to normal messages, but I'm not sure that this was a purposeful choice (6904c90). Perhaps we should print something like "potential matching loop with … eliminated by rewriting"
There was a problem hiding this comment.
It seems I've been confused about the role of these names, and indeed about their worth as well. For now, I just back out my changes that had added printing of where t#0 := ... tooltips. Separately from this PR, we should rethink whether or not we really want to do these rewrites.
| inductionVariables.Add(new IdentifierExpr(n.Tok, n)); | ||
| } | ||
| } | ||
|
|
||
| if (inductionVariables.Count != 0) { | ||
| List<List<Expression>> triggers = null; | ||
| if (lemma != null) { | ||
| triggers = ComputeInductionTriggers(inductionVariables, body, lemma.EnclosingClass.EnclosingModuleDefinition); |
There was a problem hiding this comment.
I find the logic here a bit hard to follow: we have ComputeInductionTriggers and ComputeAndReportInductionTriggers and ReportInductionTriggers, and two sets of calls for each of these methods. Is the duplication necessary? Can we add a comment why?
There was a problem hiding this comment.
I added a comment. (The reason is to get the tooltips to come out in a nice order.)
|
|
||
| Reporter.Message(MessageSource.Rewriter, warningLevel, null, tok, | ||
| $"Could not find a trigger for the induction hypothesis. Without a trigger, this may cause brittle verification. " + | ||
| $"Change or remove the {{:induction}} attribute to generate a different induction hypothesis, or add {{:nowarn}} to silence this warning. " + |
There was a problem hiding this comment.
Is there a way to make it produce a quantifier without triggers (and thus recover the previous behavior?)
There was a problem hiding this comment.
OK, I finished reading through. It looks good to me! Beyond stylistic concerns that I left in individual comments, my main worry is the impact that this will have on customers: how many proofs will be broken, and how good a transition path are we giving them? Is there an easy way to recover the previous behavior (e.g. what if we made :induction true do that, though with a warning?
(When we started generating triggers automatically we did so under a flag at first.)
|
Thanks for your useful comments, @cpitclaudel . I have addressed many and commented on others. For the good suggestion of making sure there is a way to support customers who want to keep their old possibly-trigger-less inductions, I started writing a specification in the release notes ( Currently, |
This PR aims to help stabilize verification by filling in matching patterns for the quantifiers introduced by automatic induction to represent the induction hypothesis. It also suppresses the generation of the induction hypothesis if no such matching patterns are found.
Full description
This PR computes matching patterns for the quantification that's about to be used with automatic induction. If there are no matching patterns, the induction hypothesis is not added. Tooltips or warnings show the patterns or announce the lack thereof.
The PR no longer uses arrow-typed variables as induction variables. (If a user really wants them, an
{:induction ...}attribute can be given manually.)Treat
thismore like other parameters when computing induction variables.With this PR, ternary expressions (that is,
_ ==#[_] _and_ !=#[_] _) are considered as candidate trigger expressions. In addition, a codatatype==(which is defined by Dafny as a greatest predicate) is considered as a focal predicate for extreme predicates.The PR also fixes a crash in trigger selection when the candidate expression has a lambda expression.
Finally, the "selected trigger" tooltip is extended to also show the
t := ebinding for any bound variable added as part of a quantifier rewrite.By submitting this pull request, I confirm that my contribution is made under the terms of the MIT license.