Draft
Conversation
530d850 to
6e08d3b
Compare
Collaborator
|
Should maybe counterexample validation be done on less transformed trees? How early in the pipeline does this make sense? |
6e08d3b to
589c8d6
Compare
Collaborator
|
@mario-bucev this does not appear to be an issue any more. Why did we need inlineInvariant to start with? |
Collaborator
|
This issue is still here, but |
Member
Author
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Running Stainless on this benchmark:
yields:
Notice that what should be
adt invariantVCs are justbody assertions.With this fix, Stainless then generates the right VC kinds, but then fails again during model checking with:
Because the original invariant (
inv$8) has been inlined, resulting ininv$7(Foo$0(5)), we cannot find a call for it in order to pullFoo$0(5)out from the VC and into the model to avoid the evaluator choking when evaluating the original invariant onFoo$0(5). Symbols below:To fix that, this PR stores the original, non inlined, ADT invariant within the
VCKinditself, so that we can work with the original invariant instead of the inlined one. This should be fine for model checking since there should be no semantic differences between evaluating either invariants (original or inlined).This is all very hacky, and I would be happy hear other suggestions as to how to solve this issue.