-
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
Run all proof harnesses by default #962
Conversation
oh, doh. I need to adapt bookrunner to work with needing |
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.
Sweet! Mostly minor comments. I do think we should change the behaviour to run all harnesses before failing though.
drop(ctx); | ||
std::process::exit(1); | ||
|
||
let metadata = ctx.collect_kani_metadata(&[outputs.metadata])?; |
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.
Can we move the duplicated code to a separate function?
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've tried to avoid having any functions that are specific to kani
or cargo-kani
(except these two of course) because I think these are generally design errors. You'll notice that there are several small variations between these two functions, and trying to abstract those differences out will generally make the code worse, not better.
A small amount of not-really-duplication is better than trying to create a function with a half dozen parameters that only gets called 2 ways. The old python was full of that, and it's just code that only gets worse as people add to it.
That said, I think there IS a little bit I can factor out here, I just need to fix how we do report generation first since I actually broke that...
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.
That makes sense. Thanks
match self.props.kani_panic_step { | ||
Some(KaniFailStep::Check) => { | ||
self.check(); | ||
} | ||
Some(KaniFailStep::Codegen) => { | ||
self.codegen(); | ||
} | ||
Some(KaniFailStep::Verify) | None => { | ||
self.verify(); | ||
} |
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 change is necessary since we now may run kani-compiler
from kani
with different flags that compiletest
wasn't picking up. This change means we avoid doing redundant work, and these differences only matter for things that expected to fail to check or codegen (which wasn't any existing tests, thankfully)
Just thought I'd note this in the review here, since it got mixed up with a bunch of other changes to get tests working again after switching to using --harness
This should be ready to review again. It now runs all proof harnesses even if one fails, and prints a summary at the end:
Hmm. Possibly I should print which harnesses failed, so you don't have to scroll up to search for them... Let me know your thoughts. We now also produce all reports with
I notice that the "pretty name" of function is fully qualified. I'm thinking about fixing that (advice?) but if we don't use the fully qualified names, there might be name collisions. (At the very least, colon isn't legal in filenames on windows, so we have to do something...) |
The way proof is implemented today by using That said, can you replace 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.
This is a huge step forward! Awesome work, @tedinski!
Just had a few minor comments.
println!("Verification failed for - {}", harness.pretty_name); | ||
} | ||
|
||
println!( |
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.
Should we still print this summary line when self.args.quiet
is true? cargo test
prints the summary even with --quiet
.
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.
Maybe. In my experience, there is a contingent of "if I say quiet, actually print nothing, just give me a return value" software out there. But... maybe this isn't one that should be that way.
cargo test is a compelling point of comparison. Possibly we should do some output comparisons and decide differently later?
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.
Sure.
@@ -1,8 +1,8 @@ | |||
// Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved. | |||
// SPDX-License-Identifier: Apache-2.0 OR MIT | |||
// @expect verified |
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.
Is removing the SMACK annotations necessary? They're probably meant for the SMACK testing tool, but they may be useful for us to compare results.
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.
No: I needed to quickly audit those files to fix a few things and I removed what I thought was unnecessary. I don't see how these would ever get used...
* Introduce --harness and parse kani-metadata. * run all proof harnesses * enable function-less 'expected' tests for cargo-kani in compiletest * Only mention --harness not --function in docs * use --harness instead of --function in tests, mostly. * Run all harnesses, even if one fails. Also generate all reports in separate directories * Output reports (and harness) with - not :: in file names * Print all failed harnesses in a final summary * Make harness search robust against possible future name collisions
* Introduce --harness and parse kani-metadata. * run all proof harnesses * enable function-less 'expected' tests for cargo-kani in compiletest * Only mention --harness not --function in docs * use --harness instead of --function in tests, mostly. * Run all harnesses, even if one fails. Also generate all reports in separate directories * Output reports (and harness) with - not :: in file names * Print all failed harnesses in a final summary * Make harness search robust against possible future name collisions
* Introduce --harness and parse kani-metadata. * run all proof harnesses * enable function-less 'expected' tests for cargo-kani in compiletest * Only mention --harness not --function in docs * use --harness instead of --function in tests, mostly. * Run all harnesses, even if one fails. Also generate all reports in separate directories * Output reports (and harness) with - not :: in file names * Print all failed harnesses in a final summary * Make harness search robust against possible future name collisions
* Introduce --harness and parse kani-metadata. * run all proof harnesses * enable function-less 'expected' tests for cargo-kani in compiletest * Only mention --harness not --function in docs * use --harness instead of --function in tests, mostly. * Run all harnesses, even if one fails. Also generate all reports in separate directories * Output reports (and harness) with - not :: in file names * Print all failed harnesses in a final summary * Make harness search robust against possible future name collisions
Description of changes:
--function
in favor of--harness
which must be#[kani::proof]
. Updated all documentation accordingly.kani-metadata.json
files, to support looking up proof harnesses.*.symtab.json
instead ofdry-run.symtab.json
--gen-c
to print where the file was generated.)crate-type=lib
is now unconditional and we (by documentation) require#[kani::proof]
. Technically,--function
can still specify anything but you need some method of ensuring the function gets code-gen'd.cargo-kani
andkani
now default to running all proof harnesses found.--harness
cargo-kani
mode tests. We can now add a plainexpected
file instead offunction.expected
and this will runcargo-kani
without any--function
flags.phew
Resolved issues:
Resolves #464
Resolves #691
Contributes to #477 and #701
Call-outs:
Testing:
How is this change tested? 2 new tests cases, fairly basic. Plus existing whole test suite.
Is this a refactor change? no
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.