Quantcast
Channel: Dafny: An Automatic Program Verifier for Functional Correctness
Viewing all articles
Browse latest Browse all 1106

Created Unassigned: Auto triggers do not consider math operators as candidates for triggers [124]

$
0
0

When the /noNLarith switch is used, Dafny wraps each mathematical operator in a Boogie-level function (e.g.,```INTERmul_boogie()```). Unfortunately, the auto trigger functionality doesn't know this, and hence it doesn't consider them as a possibility when selecting triggers. Here's a small example that illustrates when this is a problem. Dafny chooses power(n,e) as a trigger, but it doesn't choose "n*e", which causes problems when trying to prove the ensures clause.

```
function power(n:nat, e:nat) : int

lemma lemma_power()
ensures forall n:nat, e:nat :: 0 <= n * e && power(n, e) == 5;
{
forall n:nat, e:nat
ensures 0 <= n * e && power(n, e) == 5;
{
assume false;
}
}
```

Here's Clement's suggestion for how to fix this:

0. Extract a bit of the logic in TrExpr to construct a BinaryExpr -> bool function, checking whether a particular resolved binary expression will be rewritten as a function call
1. In Triggers/TriggersCollector.cs, edit the following line in the Annotate function to allow op to be a rewritten binary operator, if the function of step 1 returned true (one may also want to only do this for arithmetic operators, since the ones returning Booleans have a never_pattern annotation):
(expr is BinaryExpr && (((BinaryExpr)expr).Op == BinaryExpr.Opcode.NotIn || ((BinaryExpr)expr).Op == BinaryExpr.Opcode.In)))
2. To prevent the INTERNAL__* function from popping up everywhere, one would probably also want to augment the SelectTriggers function in QuantifierCollection to reject triggers that contain binary operations, unless they are the only ones that were found.
3. There is no step 3. Still, this list has 3 steps.


Viewing all articles
Browse latest Browse all 1106

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>