(Re)introduce Invariant trait#3190
Merged
adpaco-aws merged 14 commits intomodel-checking:mainfrom Jun 6, 2024
Merged
Conversation
celinval
reviewed
May 16, 2024
Contributor
Author
|
The PR is ready for review. Question: Since we're considering checking automatically these invariants at some level in the future, would it make sense to warn Kani users in the release notes? |
Invariant traitInvariant trait
celinval
reviewed
May 17, 2024
celinval
reviewed
May 24, 2024
celinval
reviewed
Jun 6, 2024
celinval
approved these changes
Jun 6, 2024
Contributor
celinval
left a comment
There was a problem hiding this comment.
Btw, great documentation. Thanks
feliperodri
approved these changes
Jun 6, 2024
Contributor
feliperodri
left a comment
There was a problem hiding this comment.
This is such a great addition. In the future, we could have something like safe_any(), which would return non-deterministic values that automatically assume the safety invariants of a type.
celinval
pushed a commit
to celinval/kani-dev
that referenced
this pull request
Jun 6, 2024
This PR reintroduces the `Invariant` trait as a mechanism for the specification of type safety invariants. The trait is defined in the Kani library where we also provide `Invariant` implementations for primitive types. In contrast to the previous `Invariant` trait, this version doesn't require the `Arbitrary` bound (i.e., it has the same requirements as `Arbitrary`). This way, the user isn't required to provide an `Arbitrary` implementation in addition to the `Invariant` one. Related model-checking#3095
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
3 participants
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.
This PR reintroduces the
Invarianttrait as a mechanism for the specification of type safety invariants. The trait is defined in the Kani library where we also provideInvariantimplementations for primitive types.In contrast to the previous
Invarianttrait, this version doesn't require theArbitrarybound (i.e., it has the same requirements asArbitrary). This way, the user isn't required to provide anArbitraryimplementation in addition to theInvariantone.Related #3095
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.