-
Notifications
You must be signed in to change notification settings - Fork 88
Add experimental generation and validation of YAML witness invariants with preconditions #752
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
Conversation
|
Although the entry type for invariants with preconditions is currently unofficial, it would be good to get this merged for its refactoring of the YAML witnesses. The refactoring makes it easy to work with different entry types, possibly including |
jerhard
left a comment
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.
We discussed this here a bit in Munich, with @michael-schwarz, @stilscher.
It probably makes sense to implement this grouping of preconditions before merging this, as otherwise the produced precondition-witnesses could be misleading.
For a function, one would first generate all the invariant expressions for the contexts, and then check which of the start states may satisfy the condition and group them. Subsequently one would generate the precondition-invariants for these groups of contexts.
In this example, among others, the following precondition_loop_invariants are generated:
loop_invariant:
string: result == 1
[...]
precondition:
string: '*ptr1 == 5 && *ptr2 == 5'
and:
loop_invariant:
string: result == 0
[...]
precondition:
string: '*ptr1 == 5 && *ptr2 == 5'
To fix this issue, grouping of precondition_loop_invariants is required.
…ed for one state. In case that an invariant for a state could not be generated, no precondition_loop_invariant is generated. Reason: The invariant (that failed to be generated) must be part of the postcondition.
…y and Function(-return) nodes to is_invariant_node
…ver all other contexts of the function
jerhard
left a comment
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!
Precondition Invariant: Disjunct over matching state invariants
Adds the experimental YAML witness entry type
precondition_loop_invariant, which is likeloop_invariant, but has a secondpreconditionexpression to match contexts.Current validation semantics is that the invariant is only checked for contexts where the precondition must hold.
Additionally refactors all the YAML witness type definitions etc to be more type-safe and extensible.