-
Notifications
You must be signed in to change notification settings - Fork 274
CONTRACTS: Front-end extensions for assigns clauses #7086
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
CONTRACTS: Front-end extensions for assigns clauses #7086
Conversation
9d1e966
to
399a2c2
Compare
Codecov ReportBase: 77.88% // Head: 77.89% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## develop #7086 +/- ##
========================================
Coverage 77.88% 77.89%
========================================
Files 1576 1576
Lines 181859 181913 +54
========================================
+ Hits 141648 141699 +51
- Misses 40211 40214 +3
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
d450da6
to
9614c1b
Compare
7baf31d
to
0d8b076
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.
I'd suggest that future PRs could be break down into smaller commits and maybe you wanna move everything related to frees clauses to the next PR (which would remove the dependency from the other PR and make both of them much cleaner). Apart from that, only small comments. Great improvement!!!
regression/contracts/reject_return_value_in_frees_clause/main.c
Outdated
Show resolved
Hide resolved
regression/contracts/reject_return_value_in_preconditions/main.c
Outdated
Show resolved
Hide resolved
regression/contracts/typed_target_fail_wrong_nof_operand/main.c
Outdated
Show resolved
Hide resolved
^SIGNAL=0$ | ||
-- | ||
-- | ||
This test checks that __CPROVER_old occurences in assigns clauses |
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.
Not true, update the description.
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.
+1
80d3b26
to
52313ad
Compare
52313ad
to
60f8feb
Compare
60f8feb
to
13e3332
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.
A few more comments but it should be good to go.
^SIGNAL=0$ | ||
-- | ||
-- | ||
This test checks that __CPROVER_old occurences in assigns clauses |
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.
+1
src/ansi-c/c_typecheck_code.cpp
Outdated
{ | ||
must_throw = true; | ||
error().source_location = target.source_location(); | ||
error() << "expected ID_conditional_target_group expression in " + |
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.
Do we want to inform users about ID_conditional_target_group
? Perhaps we could have a more informative message.
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.
The syntax section of the manual defines a conditional target group as :
conditional-target-group ::= (condition ':')? target (',' target)*
How about using conditional target group
instead of ID_conditional_target_group
to make it more human-readable ?
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 like it!
Just noting that I posted a bunch of comments in #7091 that apply to the second commit of this PR. Apologies for not noticing that I should have reviewed this one first. Will re-review this one once the updates have been made. |
13e3332
to
e851cf4
Compare
@tautschnig the |
e851cf4
to
a118518
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.
Only minor comments.
a118518
to
21dbb9b
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! @tautschnig I think this PR is ready for your final review.
|
||
## In Function Contracts | ||
An _assigns clause_ lets the user to specify which memory locations may be |
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.
s/to //
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.
fixed
|
||
## In Function Contracts | ||
An _assigns clause_ lets the user to specify which memory locations may be | ||
assigned to by a function or a loop. |
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.
Perhaps a sentence or two can be added why assigns clauses are useful/required? The above says what they describe, but (naively speaking) life would be easier if one didn't have to write any such clauses.
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.
fixed
the set of locations assigned by the loop from the loop body, | ||
and then checks that the inferred set is correct (as if specified by the user). |
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.
So why couldn't we do this for functions as well? Conversely, is it a desirable feature to have this difference in semantics of an unspecified assigns clause? Should we perhaps have a keyword auto
that's permitted in loop assigns clauses only?
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.
Thinking about it, I think we can do it today for loops because the assigns clause inference, the loop abstraction and the verification of the inferred clause all happen at the same time in the same analysis.
For function contracts we operate either in contract checking or contract replacement mode and we cannot infer check and replace the assigns clause in a single run.
In a later version we could introduce something like '__CPROVER_assigns(auto)` which would mean "when this contract is used to replace some function call, infer the set of memory locations from the code of the function, check that the result is correct in a separate analysis, and use that inferred clause to havoc state at the replacement site"
One way to figure out the side effects of a particular function could be to check it under an empty assigns clause and to turn all reported violations into an assigns clause.
2f53348
to
6bac320
Compare
minus_exprt( | ||
typecast_exprt::conditional_cast(ptr, pointer_type(char_type())), | ||
pointer_offset(ptr)), | ||
typecast_exprt::conditional_cast(object_size(ptr), size_type()), |
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.
+1
Add new functions to specify assignable targets in assigns clauses: - add polymorhpic builtin __CPROVER_typed_target - add builtin __CPROVER_assignable - add builtin __CPROVER_object_whole - add builtin __CPROVER_object_from - add builtin __CPROVER_object_upto - allow function call expressions as assigns clause targets as long as they are one of the new built-ins Using __CPROVER_POINTER_OBJECT is still allowed (for loop contracts), will be deprecated in an ulterior PR.
6bac320
to
45c677e
Compare
The first commit tags some JBMC tests as THOROUGH because they seem to exceed resources available for the ubuntu 18.04 target when building this PR
Add new functions to specify assignable targets in assigns clauses:
clause targets as long as they are one of
the new built-ins
Using __CPROVER_POINTER_OBJECT in assigns clauses is still allowed for now (needed for loop contracts),
will be deprecated in #7127.