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

Feature : Unwind attribute #1031

Merged
merged 16 commits into from
Apr 21, 2022
Merged

Conversation

jaisnan
Copy link
Contributor

@jaisnan jaisnan commented Apr 11, 2022

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:

  • How is this change tested? Tests changed to use the unwind attribute

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.

@jaisnan jaisnan requested a review from a team as a code owner April 11, 2022 18:48
Copy link
Contributor

@celinval celinval left a 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.

  1. Will the command line option --unwind and the property file unwind flag still work?
  2. If so, which one takes precedence?

We should make sure we add tests that cover those cases.

@jaisnan
Copy link
Contributor Author

jaisnan commented Apr 11, 2022

I have a few questions.

1. Will the command line option `--unwind` and the property file `unwind` flag still work?

2. 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.

@tedinski
Copy link
Contributor

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 --harness so they're only running one harness?). My vote is for ignoring this case for now and let's see what happens or if customers get confused or want the override behavior?

@jaisnan
Copy link
Contributor Author

jaisnan commented Apr 11, 2022

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 --harness so they're only running one harness?). My vote is for ignoring this case for now and let's see what happens or if customers get confused or want the override behavior?

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?

Copy link
Contributor

@adpaco-aws adpaco-aws left a 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)]

Copy link
Contributor

Choose a reason for hiding this comment

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

Remove newline?

@celinval
Copy link
Contributor

celinval commented Apr 11, 2022

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:

  1. Introduce a --default-unwind option if we want to have a weaker behavior that allows harnesses annotations to have higher precedence.
  2. Only allow --unwind in conjunction with --harness. In this case, the command line option would have higher precedence.

@jaisnan
Copy link
Contributor Author

jaisnan commented Apr 11, 2022

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:

1. Introduce a `--default-unwind` option if we want to have a weaker behavior that allows harnesses annotations to have higher precedence.

2. Only allow `--unwind` in conjunction with `--harness`. In this case, the command line option would have higher precedence.

Alright, this is what I'll implement. Thanks for your inputs everyone.

@jaisnan jaisnan requested a review from adpaco-aws April 21, 2022 14:35
Copy link
Contributor

@adpaco-aws adpaco-aws left a 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

@adpaco-aws adpaco-aws self-requested a review April 21, 2022 15:35
Copy link
Contributor

@tedinski tedinski left a 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.

docs/src/tutorial/arbitrary-variables/Cargo.toml Outdated Show resolved Hide resolved
docs/src/tutorial/loops-unwinding/Cargo.toml Outdated Show resolved Hide resolved
src/kani-driver/src/args.rs Outdated Show resolved Hide resolved
src/kani-driver/src/call_cbmc.rs Outdated Show resolved Hide resolved
src/kani-driver/src/call_cbmc.rs Outdated Show resolved Hide resolved
src/kani-driver/src/call_cbmc.rs Outdated Show resolved Hide resolved
src/kani-driver/src/call_cbmc.rs Outdated Show resolved Hide resolved
src/kani-driver/src/metadata.rs Outdated Show resolved Hide resolved
src/kani-driver/src/args.rs Outdated Show resolved Hide resolved
src/kani-driver/src/args.rs Outdated Show resolved Hide resolved
src/kani-driver/src/metadata.rs Outdated Show resolved Hide resolved
src/kani-driver/src/metadata.rs Outdated Show resolved Hide resolved
@jaisnan jaisnan merged commit 36bb27c into model-checking:main Apr 21, 2022
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 22, 2022
* Hook up unwind attribute to Kani

* Add tests and make Harness, a required argument

* Refactor tests and replace --unwind with --default-unwind
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 25, 2022
* Hook up unwind attribute to Kani

* Add tests and make Harness, a required argument

* Refactor tests and replace --unwind with --default-unwind
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 26, 2022
* Hook up unwind attribute to Kani

* Add tests and make Harness, a required argument

* Refactor tests and replace --unwind with --default-unwind
tedinski pushed a commit that referenced this pull request Apr 27, 2022
* Hook up unwind attribute to Kani

* Add tests and make Harness, a required argument

* Refactor tests and replace --unwind with --default-unwind
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Enable Unwind Attribute from Parsing metadata files
4 participants