-
Notifications
You must be signed in to change notification settings - Fork 99
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
refactor: make concrete values parser use serde trace structs #1601
Conversation
This should probably be reviewed by at least @celinval and @adpaco-aws. |
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.
This looks much cleaner. Thanks
One thing I noticed is that we are printing a lot of INFO messages on a per harness basis. I don't expect you to change that in this PR, but maybe avoid adding more for now.
kani-driver/src/concrete_playback.rs
Outdated
if verification_output.status == VerificationStatus::Success { | ||
if !self.args.quiet { | ||
println!( | ||
"INFO: The concrete playback feature does not generate unit tests when verification succeeds." |
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.
Since we have removed the --harness [h]
requirement, I think this info here might be too verbose.
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'm not sure I understand why --harness
impacts the verbosity here.
Regardless of whether that's required or not, I see how this could be a bit too verbose. I'm unclear what the correct behavior should be here: 1) print INFO, 2) quietly skip generating a unit test, 3) print ERROR and panic. I think 3) is too much. I assume that if the user inputted this flag, they expect a test case to be generated. So if it's not, 2) is too passive, and we should at least tell them with 1) (the current approach).
What are your thoughts on this?
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.
Well, if I run cargo kani
in a project where all proofs succeed (the common case if Kani is integrated in CI), this message would be printed once per proof, so I agree it's a little too verbose. What about printing if --verbose
? Another option is to change cargo kani
to print a message (only one, at the end) if the user passed the concrete playback flag but all proofs passed.
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 would expect only one INFO message at the end if all harnesses succeeded.
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.
Ah, that makes sense. It would be much less verbose when you have a bunch of successful harnesses and only one failing harness.
I updated the code to add a inform_if_no_failed
function. This informs the user at the very end if there are no failed harnesses.
@adpaco-aws do you have any additional feedback? If not, GitHub shows that you're still requesting changes. |
Edit: Looks like this magically fixed itself 🤷🏾♂️ . Disregard this. I'm getting a weird error on just the
|
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 @sanjit-bhat ! Please wait for @celinval to take another look.
@celinval can you merge into main once CI runs? I don't have write access anymore. |
Description of changes:
This PR does the following:
Resolved issues:
Resolves #1477.
Testing:
No tests were added. The CBMC output parser updates are tested via none of the existing regressions failing. The concrete values extractor is tested via all the concrete playback tests.
Yes, in some ways; no, in other ways. It is not a refactor change because it adds new fields to the CBMC output parser. It is a refactor change because the higher-level functionality of extracting concrete values still stays the same.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.