List Subcommand (Implementation) #3523
Conversation
kani-compiler/src/args.rs
Outdated
| @@ -47,6 +47,9 @@ pub struct Arguments { | |||
| pub reachability_analysis: ReachabilityType, | |||
| #[clap(long = "enable-stubbing")] | |||
| pub stubbing_enabled: bool, | |||
| /// Option name used to tell the compiler to execute the list subcommand | |||
There was a problem hiding this comment.
does the compiler need to be aware of the list?
There was a problem hiding this comment.
Per slack, no -- will fix. Going to move to draft until then, since this will take me a bit of time to do and I don't want anyone wasting time reviewing in the meantime.
| // Only emit an error if we are trying to actually verify the contract. | ||
| // (If we are running the list subcommand, we just report later that there are no contracts for this harness). | ||
| if is_list_enabled { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Why? I think this should emit a compilation error.
There was a problem hiding this comment.
People may want to write harnesses before they write the contracts. For instance, if I'm planning to write a contract for a function, I could write:
fn foo(x: usize) -> usize { ... }
#[kani::proof_for_contract(foo)]
fn harness() {
let x: usize = kani::any();
foo(x);
}before I write the contracts for foo.
It makes sense to error during verification, since we can't verify a contract that doesn't exist. But I didn't think it made sense to punish people for being halfway done; they may want to use the list command to see what work they have left to do.
That being said, I'm not even sure I could make this distinction if we're making the compiler unaware of the list command, so we may have to make it a compiler error.
Implementation of the list subcommand (and updates to the RFC).
As a larger test, I ran on the standard library (
kani list -Z list -Z function-contracts -Z mem-predicates ./library --std) and manually verified that the results were correct. I pasted the output below. mem::swap only has modifies clauses, so we list zero contracts (see the "Modifies Clauses" section of the RFC for rationale).By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.