refactor: make concrete values parser use serde trace structs#1601
Conversation
|
This should probably be reviewed by at least @celinval and @adpaco-aws. |
celinval
left a comment
There was a problem hiding this comment.
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.
| 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.
Since we have removed the --harness [h] requirement, I think this info here might be too verbose.
There was a problem hiding this comment.
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.
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.
I would expect only one INFO message at the end if all harnesses succeeded.
There was a problem hiding this comment.
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 |
adpaco
left a comment
There was a problem hiding this comment.
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.