-
Notifications
You must be signed in to change notification settings - Fork 92
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
Allow specifying the scheduling strategy in #[kani_proof] for async functions #1661
Conversation
fb768a4
to
00386e8
Compare
With #1659 merged, this is no longer blocked! I've rebased and updated this PR, but there seem to be issues with concrete playback that I don't understand (the |
Huh, seems that the tests pass in CI (not sure why they failed locally). In that case, this PR is ready for review. |
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.
Thanks @fzaiser.
Does verifying an async harnesses require the unstable flag to be passed? Is there any documentation to how an async harness is verified? What happens if no argument is passed?
Yes, it requires
There is some documentation here: https://model-checking.github.io/kani/crates/doc/kani/attr.proof.html. I just added additional information regarding
If no argument is passed, it uses
|
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.
Can you please add the following ui tests please?
- Wrong attribute argument
- No unstable flag provided
Thanks!
@celinval I added the requested tests. This should be ready to merge. |
Description of changes:
Instead of having to manually wrap the code in
kani::spawnable_block_on
as in #1659, this PR allows#[kani::proof]
to be applied to harnesses that usespawn
as well. For this to happen, the user has to specify a scheduling strategy.Resolved issues:
Resolves #ISSUE-NUMBER
Call-outs:
Testing:
How is this change tested? Additional regression test.
Is this a refactor change? No
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.