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

Implement #[kani::async_proof] attribute #1430

Merged
merged 3 commits into from
Aug 2, 2022

Conversation

fzaiser
Copy link
Contributor

@fzaiser fzaiser commented Aug 1, 2022

Description of changes:

This adds an attribute #[kani::async_proof] to make model-checking async functions more ergonomic. Before, one had to manually call kani::block_on on an async function.

Call-outs:

This adds the dependencies syn and quote to kani_macros.

Testing:

  • How is this change tested? Added a regression test.

  • Is this a refactor change? No

Checklist

  • Each commit message has a non-empty body, explaining why the change was made
  • Methods or procedures are documented
  • Regression or unit tests are included, or existing tests cover the modified code
  • My PR is restricted to a single feature or bugfix

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

@fzaiser fzaiser requested a review from a team as a code owner August 1, 2022 19:11
@fzaiser fzaiser changed the title Implement #[kani::async_proof] attribute Implement #[kani::async_proof] attribute Aug 1, 2022
let attrs = fn_item.attrs;
let vis = fn_item.vis;
let sig = fn_item.sig;
assert!(sig.asyncness.is_some(), "#[kani::async_proof] can only be applied to async functions");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably have a test for this

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

#[cfg(kani)]
#[proc_macro_attribute]
pub fn async_proof(attr: TokenStream, item: TokenStream) -> TokenStream {
assert!(attr.to_string().is_empty(), "#[kani::async_proof] does not take any arguments");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is true for now, but will probably not be true in the future if we want to control which executor we use

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I'll mention that this may change in the future.


#[cfg(kani)]
#[proc_macro_attribute]
pub fn async_proof(attr: TokenStream, item: TokenStream) -> TokenStream {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This macro is more extensive than some of the others, and could probably use a comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added.

@fzaiser fzaiser self-assigned this Aug 1, 2022
@fzaiser fzaiser merged commit 2f5bdf2 into model-checking:main Aug 2, 2022
@camshaft
Copy link
Contributor

camshaft commented Aug 3, 2022

Do we actually need a separate attribute for async? Couldn't the existing proof macro look to see if the function has an async and do the right thing if it does?

@fzaiser
Copy link
Contributor Author

fzaiser commented Aug 4, 2022

Do we actually need a separate attribute for async? Couldn't the existing proof macro look to see if the function has an async and do the right thing if it does?

@camshaft Thanks for the suggestion! I had considered that, but thought it would be better to keep them separate: we expect to extend the attribute later on to allow the user to choose different Kani executors: #[kani::async_proof(executor = "..."), similarly to tokio's #[tokio::test(flavor = "...")]. Such arguments don't make sense for non-async functions, so I thought it would be best to keep them separate. Happy to be convinced otherwise though :)

@fzaiser
Copy link
Contributor Author

fzaiser commented Aug 5, 2022

Opened #1464 to discuss

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants