-
Notifications
You must be signed in to change notification settings - Fork 97
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
Users should be able to create contracts suitable for verification but not stubbing #2997
Comments
Since the intrinsic is only internal I want to propose the name I think you should include in the description that we would want to emit a warning though or perhaps fail at compile time if we find that |
Unfortunately, the intrinsic will have to be marked as public with hidden documentation. |
This will allow us to re-use contracts between modules. We still cannot compile our contracts due to model-checking#2997
Allow contracts to be used for verification, even if it is not suitable for stubbing. For that, we remove the requirement that modifies and return types of a function annotated with contracts must implement `kani::Arbitrary`, since that is only needed for recursion and stubbing with contract. This is done via a new intrinsic `any_modifies` to Kani that should only be used by contract instrumentation. The `T: Arbitrary` requirement is only checked when users try to use the contract as stub or to check recursive functions. For now, we also require users to annotate their contracts with `kani::recursion` if they want to use inductive reasoning to verify a recursive function. Resolves #2997. By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses. --------- Signed-off-by: Felipe R. Monteiro <felisous@amazon.com>
This will allow us to re-use contracts between modules. We still cannot compile our contracts due to model-checking#2997
Requested feature: Enable contract verification for functions that Kani cannot use as stub today.
Use case: Verification of functions that return types that do not implement
Arbitrary
.Link to relevant documentation (Rust reference, Nomicon, RFC):
Test case:
Context
Kani today automatically synthesize the contract into a verification wrapper and a stub. The stub, however, rely on the fact that the return value, and the target for the modifies clauses, to implement
Arbitrary
trait. Thus, writing a simple contract for the example above would fail to compile.Possible solution
As discussed with @JustusAdam, one possible solution is to create a new intrinsic for Kani, which tries to instantiate
kani::any()
for the return / modifies type. If the instantiation fails, we can trigger a compilation error. This will only fails if a harness tries to instantiate the generated stub.The text was updated successfully, but these errors were encountered: