-
Notifications
You must be signed in to change notification settings - Fork 100
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
Feature : Unwind attribute #1031
Feature : Unwind attribute #1031
Conversation
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.
I have a few questions.
- Will the command line option
--unwind
and the property fileunwind
flag still work? - If so, which one takes precedence?
We should make sure we add tests that cover those cases.
Thanks for the callout, for now, the flags or the property file values for unwind have been disabled (we can enable them if we want). i didn't know which one should take preference over the other so I disabled the flag for now to prevent confusion. imo, we should either disable the command line flag or make it have preference over the attribute value. Allowing the command line argument but having it be low preference doesnt make much sense to me. Would like to know thoughts on how to proceed. |
Ah yeah, there are some options for that behavior aren't there? Since we now run all proof harnesses by default, I propose: (1) We always use the unwind flag on the proof harness if present. (2) if not present, only then do we pay attention to the global command line flag. In short, the command line only sets the global default, a flag on the harness always has precedence. This might be unexpected behavior if people expect to be able to override the unwind flag from the command line however, but I think that would only make sense to do in some circumstances (like if they've also provided |
This behavior makes more sense to me now than the one I proposed. command line value for the global value; and attribute value for each harnesses (which should be higher in hierarchy as it's more specific as a request from the user) @celinval, any thoughts? |
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.
Documentation must be updated to describe the feature, and whatever behavior you agree on for precedence should be noted there as well.
In my opinion, we should not be silent about conflicts and emit a user warning in this scenario (regardless of preference). Otherwise users could become really confused.
extern crate kani; | ||
|
||
use kani::any; | ||
|
||
#[kani::proof] | ||
#[kani::unwind(3)] | ||
|
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.
Remove newline?
IMO, the precedence order should be command line, harness attribute, configuration file. That said, I think it will be hard to implement this today given how we merge the configuration file options with the command line one. I'm OK with @tedinski 's suggestion but I also agree with @adpaco-aws that we shouldn't be silent about any conflict. My suggestion is to do the following:
|
Alright, this is what I'll implement. Thanks for your inputs everyone. |
…able-unwind-attribute
…able-unwind-attribute
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.
Documentation is being added in #1087
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.
There's a couple of stray changes that should be cleaned up, but the main thing is the testing.
…able-unwind-attribute
…able-unwind-attribute
* Hook up unwind attribute to Kani * Add tests and make Harness, a required argument * Refactor tests and replace --unwind with --default-unwind
* Hook up unwind attribute to Kani * Add tests and make Harness, a required argument * Refactor tests and replace --unwind with --default-unwind
* Hook up unwind attribute to Kani * Add tests and make Harness, a required argument * Refactor tests and replace --unwind with --default-unwind
* Hook up unwind attribute to Kani * Add tests and make Harness, a required argument * Refactor tests and replace --unwind with --default-unwind
Description of changes:
Cargo-kani and kani do not have the unwind attribute enabled as a feature, this PR enables kani and cargo-kani to read from the metadata and use the unwind attribute.
Tests explicitly pass the unwind value in the flags. with these changes, we can just use the attribute over the harnesses.
Resolved issues:
Resolves #1027
Testing:
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.