-
Notifications
You must be signed in to change notification settings - Fork 274
Supports quantifiers in function contracts #5959
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supports quantifiers in function contracts #5959
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #5959 +/- ##
===========================================
- Coverage 75.01% 74.05% -0.97%
===========================================
Files 1431 1444 +13
Lines 155609 157328 +1719
===========================================
- Hits 116732 116503 -229
- Misses 38877 40825 +1948
Continue to review full report at Codecov.
|
5d3cffc
to
70fc83f
Compare
I have assess all code review comments with the exception of this comment about using |
72c857a
to
8a50d78
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, I only spotted a few more typos and minor comments. Thank you for implementing all comments!!
// TODO Currently only works if the contract contains only a single | ||
// quantified formula | ||
// i.e. (1) the top-level element is a quantifier formula | ||
// and (2) there are no inner quantifier formulae |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you tag here the GitHub issue to track this comment?
8a50d78
to
1fe5bd8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. In the perfect world, the code changes and the regression tests would be in separate commits but don't worry about changing that unless you have to push a new version.
The current implementation cannot handle a structure such as | ||
__CPROVER_assume(__CPROVER_exists(int i; pred(i))), where i is | ||
not explicitly bounded to a predefined range (i.e. if at least | ||
one of its bound is only declared and not defined). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you tried the SMT back-end?
// TODO Currently only works if the contract contains only a single | ||
// quantified formula | ||
// i.e. (1) the top-level element is a quantifier formula | ||
// and (2) there are no inner quantifier formulae |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should be an INVARIANT
because it can be triggered by user input. Some kind of warning / error and an issue would be amazing.
|
||
int main() | ||
{ | ||
int len, arr[8]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think len
should also be initialized (to 8).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Such a case is already tested for in the quantifiers-forall-both-01
test, and it works with the current implementation. The purpose of this test is in fact to check wether CBMC can handle cases where the range of the quantified variable is not explicitly set a priori.
This adds basic support for quantifiers in funtion contracts. Current support only handles cases where a function contract contains a single, non-nested quantified formula.
1fe5bd8
to
edeaf56
Compare
This PR adds support for quantified expressions in function contracts. The current implementation handles cases where a function contract is only composed of a single quantified expression. Additionally, nested quantified expressions are not yet supported.
This PR might be a continuation of #2278.
Additionally, #5968 is a follow-up to this PR.