Open EmilyOng opened 10 months ago
I think the way to fix this is to always unfold non-recursive predicates during entailment. Something like this should work:
visit_HigherOrder
) to check if the predicate name occurs in any function stages. We can deal with mutual recursion later.
Issue
This program fails to prove the entailment for
main
.The above program gives the following specification.
It fails to prove the entailment because, in the entailment process for
main
:(a)
id (v22)
is unfolded asv22(i,v15) == ens v15=i
, giving the specification:(b)
call_ret
is unfolded ascall_ret(f,res) == ex v0; f(100, v0); ens res=v0
, giving the specification:Here,
call_ret
has to be unfolded because the inferred specification (in the first step) is not used. But, the unfolding introduces an additional appearanceid (v22)
, and we are required to unfoldid (v22)
again (I think the only heuristic available for use here is to unfold).Note (from discussion)
A workaround requires one to provide an explicit specification
ex v0; f(100, v0); ens res=v0
tocall_ret
. This works because we can use the inferred specification directly and avoid an additional unfold ofid (v22)
. Another workaround is to increase the unfolding bound to 2 to accommodate the additional unfolding ofid (v22)
.Questions
We can use the
rec_flag
(from parsing) to allow unfolding of non-recursive predicates during the entailment as discussed, or to directly use the inferred specification when analyzing the method.