dafny Issue Tracker Rss Feedhttps://dafny.codeplex.com/workitem/list/basicdafny Issue Tracker Rss DescriptionClosed Unassigned: Lemmas tutorial: typo and "How Dafny Works" [149]http://dafny.codeplex.com/workitem/149The [Lemmas tutorial](http://rise4fun.com/Dafny/tutorial/Lemmas) states and proves a "distributive lemma" of the `count` function. However, the lemmas statement is not type correct, because `count` expects `seq<bool>` but the lemmas passes `seq<int>`.<br /><br />The tutorial also refers to "How Dafny Works". I didn't find anything useful by googling that phrase. What is this referring to?<br />rustanleinoThu, 20 Oct 2016 00:37:43 GMTClosed Unassigned: Lemmas tutorial: typo and "How Dafny Works" [149] 20161020123743ACommented Unassigned: Lemmas tutorial: typo and "How Dafny Works" [149]http://dafny.codeplex.com/workitem/149The [Lemmas tutorial](http://rise4fun.com/Dafny/tutorial/Lemmas) states and proves a "distributive lemma" of the `count` function. However, the lemmas statement is not type correct, because `count` expects `seq<bool>` but the lemmas passes `seq<int>`.<br /><br />The tutorial also refers to "How Dafny Works". I didn't find anything useful by googling that phrase. What is this referring to?<br />Comments: FixedrustanleinoThu, 20 Oct 2016 00:37:29 GMTCommented Unassigned: Lemmas tutorial: typo and "How Dafny Works" [149] 20161020123729ACommented Unassigned: termination metric [174]http://dafny.codeplex.com/workitem/174<br /><br />http://rise4fun.com/Dafny/yLsls<br /><br />Why the hover text in MVS says only "decreases" for the outermost while?<br />Comments: I'm sorry I realized now that it is not only the decreases expression, but Dafny is not working properly on the partial correctness of the previous program and also on this one http://rise4fun.com/Dafny/v5fA that is obviously incorrect, but Dafny does not detect it. jiplucapTue, 11 Oct 2016 14:30:50 GMTCommented Unassigned: termination metric [174] 20161011023050PCreated Unassigned: termination metric [174]http://dafny.codeplex.com/workitem/174<br /><br />http://rise4fun.com/Dafny/yLsls<br /><br />Why the hover text in MVS says only "decreases" for the outermost while?<br />jiplucapTue, 11 Oct 2016 14:02:25 GMTCreated Unassigned: termination metric [174] 20161011020225PCommented Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />Comments: Thanks a lot.jiplucapMon, 03 Oct 2016 16:01:36 GMTCommented Unassigned: Assertion violation - induction hypothesis [173] 20161003040136PCommented Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />Comments: My guess is that the proof being constructed goes something like this: http://rise4fun.com/Dafny/0FG7 ``` function power(b:int,e:nat):int { if e == 0 then 1 else b*power(b,e-1) } lemma {:induction false} Lemma_SquareAndHalve(b:int, e:nat) 	requires e%2 == 0 && e > 0 	ensures power(b,e) == power(b*b,e/2); { if e == 2 { assert power(b,2) == b*power(b,1) == power(b*b,1); 		 } else { 		calc { 			 power(b*b,e/2); 			 == 			 b*b*power(b*b,(e/2)-1); 			 == 			 b*b*b*b*power(b*b,(e/2)-2); 			 == 			 b*b*b*b*power(b*b,(e-4)/2); 			 == {if(e>4) { Lemma_SquareAndHalve(b,e-4);} else {assert (e-4)/2 == 0;} } 			 b*b*b*b*power(b,e-4); 			 == 			 b*b*power(b,e-2); 			 == 			 power(b,e); 		 } 	 } } ```lexicalscopeMon, 03 Oct 2016 15:29:21 GMTCommented Unassigned: Assertion violation - induction hypothesis [173] 20161003032921PCommented Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />Comments: You can disable automatic induction using an anotation ``` lemma {:induction false} Lemma_SquareAndHalve(b:int, e:nat) ```lexicalscopeMon, 03 Oct 2016 15:26:42 GMTCommented Unassigned: Assertion violation - induction hypothesis [173] 20161003032642PCommented Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />Comments: http://rise4fun.com/Dafny/jsv2 In this case the induction hypothesis does not should be applied, but apparently it is applied, though one of its preconditions is violated. I know that there is a simpler proof of the lemma, but I would like to know why this exactly works.jiplucapMon, 03 Oct 2016 14:37:06 GMTCommented Unassigned: Assertion violation - induction hypothesis [173] 20161003023706PCommented Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />Comments: Non-linear arithmetic is not decidable by the underlying SMT solver. So you probably need to give Dafny some more help with the % operator.lexicalscopeTue, 20 Sep 2016 13:15:21 GMTCommented Unassigned: Assertion violation - induction hypothesis [173] 20160920011521PCreated Unassigned: Assertion violation - induction hypothesis [173]http://dafny.codeplex.com/workitem/173Please, some help with the following assertion violation<br />http://rise4fun.com/Dafny/cLnNL<br /><br />jiplucapTue, 20 Sep 2016 10:21:46 GMTCreated Unassigned: Assertion violation - induction hypothesis [173] 20160920102146ACommented Unassigned: Verification result depends on declaration order [152]http://dafny.codeplex.com/workitem/152The following two files (uploaded to rise4fun) are identical except for the order in which a lemma appears while the verification result is not the same.<br /><br />An assertion error is produced when [the lemma is the last declaration in the file](http://rise4fun.com/Dafny/axBt); when [it is the first](http://rise4fun.com/Dafny/WPrWC), the file verifies correctly.<br /><br />Tested at the command line with Dafny 1.9.7 and in rise4fun.<br />Comments: Thanks for your answer. Using the current repository [version](https://github.com/Microsoft/dafny/commit/5eb855972c191ed6323253329fc50ebd1683fdd6) from command line, the verifier produces different verification outcome not only without read clauses but also with them (`reads edges` in *ValidGraph* and *PathCost*). When the lemma is the first declaration in the file, no errors are produced. When it is the last, an assertion violation is reported around line 126 with `path[1..][..i] == path[1..i+1]`. ruvusMon, 04 Jul 2016 10:23:09 GMTCommented Unassigned: Verification result depends on declaration order [152] 20160704102309ACommented Unassigned: Verification result depends on declaration order [152]http://dafny.codeplex.com/workitem/152The following two files (uploaded to rise4fun) are identical except for the order in which a lemma appears while the verification result is not the same.<br /><br />An assertion error is produced when [the lemma is the last declaration in the file](http://rise4fun.com/Dafny/axBt); when [it is the first](http://rise4fun.com/Dafny/WPrWC), the file verifies correctly.<br /><br />Tested at the command line with Dafny 1.9.7 and in rise4fun.<br />Comments: Thanks for the bug report (from April). There are two things going on with this example. One thing is that there was a bug in Dafny in the checking of reads clause for multi-dimensional arrays. That has now been fixed (see https://dafny.codeplex.com/workitem/146). With this bug fix, Dafny complains about missing reads clauses. After adding the missing reads clauses, the programs both verify. The other thing is that one gets different results depending on the declaration order (as the title of your report says). Sadly, this is still the case for your programs (without reads clauses) even after the bug fix of #146. (In the absence of the reads clauses--which Dafny now properly complains about--the frame axioms that Dafny uses allow you to derive false. My hunch is that the verifier doesn't always discover the proof of false in the same way, thus giving rise to different error reporting.) We are investing effort into eliminating or reducing these sorts of unpredictable results, so we appreciate your report. Thanks, Rustan rustanleinoSat, 02 Jul 2016 01:06:45 GMTCommented Unassigned: Verification result depends on declaration order [152] 20160702010645ACreated Unassigned: attribute parsing does not allow type parameters [172]http://dafny.codeplex.com/workitem/172If `f` is a polymorphic function with one type argument, then (for example) `f<int>` is a legal expression in Dafny. Depending on the context, `f` may also be a legal expression, provided that the type argument can be inferred (but it is not legal if the type argument cannot be inferred, because expressions in Dafny are never polymorphic). Apparently, the parsing of attribute arguments does not allow `f<int>` to be parsed, which is a bug.<br /><br />Repro: The example below parses, type checks, and verifies. However, the more natural way to write the `fuel` attribute on lemma `Threes` would be simply:<br /><br />```<br />{:fuel fold, 2} <br />```<br /><br />which isn't accepted today.<br /><br /> Rustan<br /><br />```<br />function triple(xs: List<int>): List<int><br />{<br /> match xs<br /> case Nil => Nil<br /> case Cons(x, tail) => Cons(x, Cons(x, Cons(x, triple(tail))))<br />}<br /><br />lemma {:fuel (fold<int,int>), 2} Threes(xs: List<int>)<br /> ensures fold((a,b) => a + b, 0, triple(xs)) % 3 == 0<br />{<br />}<br /><br />function fold<A,B>(f: (A,B) -> B, z: B, xs: List<A>): B<br /> requires Total(f)<br />{<br /> match xs<br /> case Nil => z<br /> case Cons(a, tail) => f(a, fold(f, z, tail))<br />}<br /><br />datatype List<A> = Nil | Cons(head: A, tail: List<A>)<br /><br />predicate Total<A,B,C>(f: (A, B) -> C)<br /> reads f.reads<br />{<br /> forall a,b :: f.reads(a,b) == {} && f.requires(a,b)<br />}<br />```<br /><br /><br />rustanleinoSat, 18 Jun 2016 00:18:34 GMTCreated Unassigned: attribute parsing does not allow type parameters [172] 20160618121834ACreated Unassigned: Empty set membership assertion produces Boogie error [171]http://dafny.codeplex.com/workitem/171The code<br />```<br />assert forall x:int :: x !in {};<br />```<br />produces the following error message<br />```<br />stdin.dfy(2,9): Error: trigger must mention all quantified variables, but does not mention: x#1<br />1 name resolution errors detected in D:\local\Temp\stdin.bpl<br /><br />*** Encountered internal translation error - re-running Boogie to get better debug information<br /><br />D:\local\Temp\stdin.bpl(1753,31): Error: trigger must mention all quantified variables, but does not mention: x#1<br />1 name resolution errors detected in D:\local\Temp\stdin.bpl<br />```<br />laurejtFri, 17 Jun 2016 22:44:40 GMTCreated Unassigned: Empty set membership assertion produces Boogie error [171] 20160617104440PClosed Unassigned: Specialized predicates should include mutually recursive predicates [170]http://dafny.codeplex.com/workitem/170Dafny performs some rewrites in an `inductive lemma` and in a `colemma`. This bug report pertains to the rewrite that is being done with the "focus predicates" (aka "specialized predicates") of the `inductive lemma` or `colemma`. A focus predicate for an `inductive lemma` is an `inductive predicate` that occurs in the lemma's precondition; a focus predicate for a `colemma` is a `copredicate` that occurs in the lemma's postcondition. If an inductive/co-lemma is specialized for an inductive/co-predicate `P`, then in the body of the lemma, Dafny will rewrite calls to `P` into calls to `P#[_k-1]`.<br /><br />The bug is that if `P` is found to be a focus predicate, then all other inductive/co-predicates in `P`'s strongly connected component (that is, all inductive/co-predicates that are mutually recursive with `P`) should also be included as focus predicates.<br /><br />I imagine that the code currently does something like:<br /><br />* Find the set S of focus predicates in the lemma's pre- or postcondition.<br />* NEW STEP TO FIX THE BUG: For every inductive/co-predicate `P` in S, add to S all inductive/co-predicates in the same strongly connected component (in the call graph) as `P`<br />* Add a hover text to the lemma, saying "specialized for ...members of S..."<br />* Do the rewrite in the body of the lemma<br /><br />I imagine that three of these steps are already done (probably in the order I described), but the "NEW STEP" needs to be implemented. Once that step is implemented, I think the hover text and the rewriting should not need any further change.<br /><br />In the test examples I'm including below, there are currently four places where verification errors occur. I expect that fixing the bug in the way I just described will cause everything to verify in this test file. (I don't know if the bug fix perhaps causes other things to break in the test suite; if so, let's talk if there's any confusion.) Optionally, the .expect file for this new test file could turn on `/printTooltips`, so that the test also shows the "specialized for ..." text.<br /><br />Thanks,<br /> Rustan<br /><br />```<br />module InductiveThings {<br /> predicate P(x: int)<br /> predicate Q(x: int)<br /><br /> inductive predicate A(x: int)<br /> {<br /> P(x) || B(x+1)<br /> }<br /><br /> inductive predicate B(x: int)<br /> {<br /> Q(x) || A(x+1)<br /> }<br /><br /> inductive lemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> requires A(x)<br /> {<br /> if B(x+1) { // this one should be replaced by B#[_k-1](x+1)<br /> BB(x+1);<br /> }<br /> }<br /><br /> inductive lemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> requires B(x)<br /> {<br /> if A(x+1) { // this one should be replaced by A#[_k-1](x+1)<br /> AA(x+1);<br /> }<br /> }<br />}<br /><br />module CoThings {<br /> copredicate A(x: int)<br /> {<br /> B(x+1)<br /> }<br /><br /> copredicate B(x: int)<br /> {<br /> A(x+1)<br /> }<br /><br /> colemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> ensures A(x)<br /> {<br /> BB(x+1);<br /> assert B(x+1); // this one should be replaced by B#[_k-1] (which will happen, provided that AA is listed as also being specialized for B)<br /> }<br /><br /> colemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> ensures B(x)<br /> {<br /> AA(x+1);<br /> assert A(x+1); // this one should be replaced by A#[_k-1] (which will happen, provided that BB is listed as also being specialized for A)<br /> }<br />}<br />```<br /><br /><br />qunyanmThu, 16 Jun 2016 19:52:33 GMTClosed Unassigned: Specialized predicates should include mutually recursive predicates [170] 20160616075233PEdited Unassigned: Specialized predicates should include mutually recursive predicates [170]http://dafny.codeplex.com/workitem/170Dafny performs some rewrites in an `inductive lemma` and in a `colemma`. This bug report pertains to the rewrite that is being done with the "focus predicates" (aka "specialized predicates") of the `inductive lemma` or `colemma`. A focus predicate for an `inductive lemma` is an `inductive predicate` that occurs in the lemma's precondition; a focus predicate for a `colemma` is a `copredicate` that occurs in the lemma's postcondition. If an inductive/co-lemma is specialized for an inductive/co-predicate `P`, then in the body of the lemma, Dafny will rewrite calls to `P` into calls to `P#[_k-1]`.<br /><br />The bug is that if `P` is found to be a focus predicate, then all other inductive/co-predicates in `P`'s strongly connected component (that is, all inductive/co-predicates that are mutually recursive with `P`) should also be included as focus predicates.<br /><br />I imagine that the code currently does something like:<br /><br />* Find the set S of focus predicates in the lemma's pre- or postcondition.<br />* NEW STEP TO FIX THE BUG: For every inductive/co-predicate `P` in S, add to S all inductive/co-predicates in the same strongly connected component (in the call graph) as `P`<br />* Add a hover text to the lemma, saying "specialized for ...members of S..."<br />* Do the rewrite in the body of the lemma<br /><br />I imagine that three of these steps are already done (probably in the order I described), but the "NEW STEP" needs to be implemented. Once that step is implemented, I think the hover text and the rewriting should not need any further change.<br /><br />In the test examples I'm including below, there are currently four places where verification errors occur. I expect that fixing the bug in the way I just described will cause everything to verify in this test file. (I don't know if the bug fix perhaps causes other things to break in the test suite; if so, let's talk if there's any confusion.) Optionally, the .expect file for this new test file could turn on `/printTooltips`, so that the test also shows the "specialized for ..." text.<br /><br />Thanks,<br /> Rustan<br /><br />```<br />module InductiveThings {<br /> predicate P(x: int)<br /> predicate Q(x: int)<br /><br /> inductive predicate A(x: int)<br /> {<br /> P(x) || B(x+1)<br /> }<br /><br /> inductive predicate B(x: int)<br /> {<br /> Q(x) || A(x+1)<br /> }<br /><br /> inductive lemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> requires A(x)<br /> {<br /> if B(x+1) { // this one should be replaced by B#[_k-1](x+1)<br /> BB(x+1);<br /> }<br /> }<br /><br /> inductive lemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> requires B(x)<br /> {<br /> if A(x+1) { // this one should be replaced by A#[_k-1](x+1)<br /> AA(x+1);<br /> }<br /> }<br />}<br /><br />module CoThings {<br /> copredicate A(x: int)<br /> {<br /> B(x+1)<br /> }<br /><br /> copredicate B(x: int)<br /> {<br /> A(x+1)<br /> }<br /><br /> colemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> ensures A(x)<br /> {<br /> BB(x+1);<br /> assert B(x+1); // this one should be replaced by B#[_k-1] (which will happen, provided that AA is listed as also being specialized for B)<br /> }<br /><br /> colemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> ensures B(x)<br /> {<br /> AA(x+1);<br /> assert A(x+1); // this one should be replaced by A#[_k-1] (which will happen, provided that BB is listed as also being specialized for A)<br /> }<br />}<br />```<br /><br /><br />qunyanmThu, 16 Jun 2016 19:52:27 GMTEdited Unassigned: Specialized predicates should include mutually recursive predicates [170] 20160616075227PClosed Unassigned: Frustrating wait for Dafny IDE to process changes [130]http://dafny.codeplex.com/workitem/130The new Dafny Visual Studio plugin waits for a noticeable amount of time (2 seconds?) before re-verifying newly written code, but I've come to find this delay frustrating. I'd like a button I can press (e.g., F11?) that will tell the plugin to start re-verifying right away rather than waiting.<br /><br />Also, when I load a new file, or reload a file that I changed in another editor (say, emacs), I'd like to not have to wait for the 2-second delay. After all, the 2-second delay was introduced to avoid conflict with subsequent keystrokes, but a load or reload shouldn't be expected to be followed by keystrokes. So, if possible, I'd like the plugin to react to a notification that the file was loaded or reloaded by re-verifying immediately.<br /><br />qunyanmThu, 16 Jun 2016 18:47:25 GMTClosed Unassigned: Frustrating wait for Dafny IDE to process changes [130] 20160616064725PCommented Unassigned: Frustrating wait for Dafny IDE to process changes [130]http://dafny.codeplex.com/workitem/130The new Dafny Visual Studio plugin waits for a noticeable amount of time (2 seconds?) before re-verifying newly written code, but I've come to find this delay frustrating. I'd like a button I can press (e.g., F11?) that will tell the plugin to start re-verifying right away rather than waiting.<br /><br />Also, when I load a new file, or reload a file that I changed in another editor (say, emacs), I'd like to not have to wait for the 2-second delay. After all, the 2-second delay was introduced to avoid conflict with subsequent keystrokes, but a load or reload shouldn't be expected to be followed by keystrokes. So, if possible, I'd like the plugin to react to a notification that the file was loaded or reloaded by re-verifying immediately.<br /><br />Comments: The delay has been removed. You can also use F5 to stop/start verifier and F11 to stop/start resolver (including the verifier) manually.qunyanmThu, 16 Jun 2016 18:47:20 GMTCommented Unassigned: Frustrating wait for Dafny IDE to process changes [130] 20160616064720PEdited Unassigned: Frustrating wait for Dafny IDE to process changes [130]http://dafny.codeplex.com/workitem/130The new Dafny Visual Studio plugin waits for a noticeable amount of time (2 seconds?) before re-verifying newly written code, but I've come to find this delay frustrating. I'd like a button I can press (e.g., F11?) that will tell the plugin to start re-verifying right away rather than waiting.<br /><br />Also, when I load a new file, or reload a file that I changed in another editor (say, emacs), I'd like to not have to wait for the 2-second delay. After all, the 2-second delay was introduced to avoid conflict with subsequent keystrokes, but a load or reload shouldn't be expected to be followed by keystrokes. So, if possible, I'd like the plugin to react to a notification that the file was loaded or reloaded by re-verifying immediately.<br /><br />qunyanmThu, 16 Jun 2016 18:47:20 GMTEdited Unassigned: Frustrating wait for Dafny IDE to process changes [130] 20160616064720PCreated Unassigned: Specialized predicates should include mutually recursive predicates [170]http://dafny.codeplex.com/workitem/170Dafny performs some rewrites in an `inductive lemma` and in a `colemma`. This bug report pertains to the rewrite that is being done with the "focus predicates" (aka "specialized predicates") of the `inductive lemma` or `colemma`. A focus predicate for an `inductive lemma` is an `inductive predicate` that occurs in the lemma's precondition; a focus predicate for a `colemma` is a `copredicate` that occurs in the lemma's postcondition. If an inductive/co-lemma is specialized for an inductive/co-predicate `P`, then in the body of the lemma, Dafny will rewrite calls to `P` into calls to `P#[_k-1]`.<br /><br />The bug is that if `P` is found to be a focus predicate, then all other inductive/co-predicates in `P`'s strongly connected component (that is, all inductive/co-predicates that are mutually recursive with `P`) should also be included as focus predicates.<br /><br />I imagine that the code currently does something like:<br /><br />* Find the set S of focus predicates in the lemma's pre- or postcondition.<br />* NEW STEP TO FIX THE BUG: For every inductive/co-predicate `P` in S, add to S all inductive/co-predicates in the same strongly connected component (in the call graph) as `P`<br />* Add a hover text to the lemma, saying "specialized for ...members of S..."<br />* Do the rewrite in the body of the lemma<br /><br />I imagine that three of these steps are already done (probably in the order I described), but the "NEW STEP" needs to be implemented. Once that step is implemented, I think the hover text and the rewriting should not need any further change.<br /><br />In the test examples I'm including below, there are currently four places where verification errors occur. I expect that fixing the bug in the way I just described will cause everything to verify in this test file. (I don't know if the bug fix perhaps causes other things to break in the test suite; if so, let's talk if there's any confusion.) Optionally, the .expect file for this new test file could turn on `/printTooltips`, so that the test also shows the "specialized for ..." text.<br /><br />Thanks,<br /> Rustan<br /><br />```<br />module InductiveThings {<br /> predicate P(x: int)<br /> predicate Q(x: int)<br /><br /> inductive predicate A(x: int)<br /> {<br /> P(x) || B(x+1)<br /> }<br /><br /> inductive predicate B(x: int)<br /> {<br /> Q(x) || A(x+1)<br /> }<br /><br /> inductive lemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> requires A(x)<br /> {<br /> if B(x+1) { // this one should be replaced by B#[_k-1](x+1)<br /> BB(x+1);<br /> }<br /> }<br /><br /> inductive lemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> requires B(x)<br /> {<br /> if A(x+1) { // this one should be replaced by A#[_k-1](x+1)<br /> AA(x+1);<br /> }<br /> }<br />}<br /><br />module CoThings {<br /> copredicate A(x: int)<br /> {<br /> B(x+1)<br /> }<br /><br /> copredicate B(x: int)<br /> {<br /> A(x+1)<br /> }<br /><br /> colemma AA(x: int) // should be specialized not just for A, but also for B, which is in the same strongly connected component as A in the call graph<br /> ensures A(x)<br /> {<br /> BB(x+1);<br /> assert B(x+1); // this one should be replaced by B#[_k-1] (which will happen, provided that AA is listed as also being specialized for B)<br /> }<br /><br /> colemma BB(x: int) // should be specialized not just for B, but also for A, which is in the same strongly connected component as B in the call graph<br /> ensures B(x)<br /> {<br /> AA(x+1);<br /> assert A(x+1); // this one should be replaced by A#[_k-1] (which will happen, provided that BB is listed as also being specialized for A)<br /> }<br />}<br />```<br /><br /><br />rustanleinoWed, 15 Jun 2016 23:42:35 GMTCreated Unassigned: Specialized predicates should include mutually recursive predicates [170] 20160615114235P