Skip to content
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

Closed
celinval opened this issue Feb 6, 2024 · 2 comments · Fixed by #3098
Closed
Assignees
Labels
[C] Feature / Enhancement A new feature request or enhancement to an existing feature.

Comments

@celinval
Copy link
Contributor

celinval commented Feb 6, 2024

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:

impl<T> NonNull<T> {
    pub unsafe fn as_ref<'a>(&self) -> &'a T { /* body */ }

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.

@celinval celinval added the [C] Feature / Enhancement A new feature request or enhancement to an existing feature. label Feb 6, 2024
@celinval celinval added this to the Function Contracts MVP milestone Feb 6, 2024
@JustusAdam
Copy link
Contributor

JustusAdam commented Feb 6, 2024

Since the intrinsic is only internal I want to propose the name conjure, because it evokes creation but also magic, which this is in a way given that it's only implementable with compiler magic.

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 conjure is reachable.

@celinval
Copy link
Contributor Author

celinval commented Feb 6, 2024

Unfortunately, the intrinsic will have to be marked as public with hidden documentation.

celinval added a commit to celinval/kani-dev that referenced this issue Mar 25, 2024
This will allow us to re-use contracts between modules.
We still cannot compile our contracts due to
model-checking#2997
feliperodri added a commit that referenced this issue Apr 2, 2024
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>
celinval added a commit to celinval/kani-dev that referenced this issue May 14, 2024
This will allow us to re-use contracts between modules.
We still cannot compile our contracts due to
model-checking#2997
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Feature / Enhancement A new feature request or enhancement to an existing feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants