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

Fix check_cast harness #86

Merged
merged 1 commit into from
Sep 18, 2024

Conversation

carolynzech
Copy link

@carolynzech carolynzech commented Sep 17, 2024

Modifies the check_cast harness to:

  • Be a proof instead of a proof for contract
  • Remove the generic type parameter

Currently, Kani doesn't run this harness. (See the log from a recent PR). It doesn't run the harness because it has a generic type parameter, and Kani's error handling for contract proofs doesn't check for this condition. (PR to fix is here). Once we remove the generic type parameter so that the harness runs, Kani complains that we can't run it as a proof for contract because there are no contracts, so we make it a regular proof instead.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

@carolynzech carolynzech merged commit 351e958 into model-checking:main Sep 18, 2024
7 of 8 checks passed
@carolynzech carolynzech deleted the remove-generic branch September 18, 2024 18:00
github-merge-queue bot pushed a commit to model-checking/kani that referenced this pull request Sep 18, 2024
Kani enforces that `[kani::proof]` attribute is not applied to generic
functions. We do not currently enforce this restriction on contract
harnesses. When the compiler [searches for harnesses to
verify](https://github.com/model-checking/kani/blob/dba8f3926a61025f5078de787ebd8d21278333ca/kani-compiler/src/kani_middle/codegen_units.rs#L63),
it only looks at monomorphized functions. Thus, currently a user can
write this code:

```rust
#[kani::requires(true)]
fn foo() {}

#[kani::proof_for_contract(foo)]
fn check_foo<T>() {
    foo()
}
```

and get 

"No proof harnesses (functions with #[kani::proof]) were found to
verify."

In the case where a user is running many harnesses, they may not notice
that Kani skipped the harness. For example, we currently have [this
harness](https://github.com/model-checking/verify-rust-std/blob/149f6dd5409fac01a983d7b98c51d51666c74e45/library/core/src/ptr/unique.rs#L288)
in the standard library, which doesn't actually run. (PR to fix is
[here](model-checking/verify-rust-std#86)).
After this PR merges, the code snippet above would instead error with:

```rust
error: the '#[kani::proof_for_contract]' attribute cannot be applied to generic functions
 --> src/lib.rs:4:1
  |
4 | #[kani::proof_for_contract(foo)]
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: this error originates in the attribute macro `kani::proof_for_contract` (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to 1 previous error
```


By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
szlee118 pushed a commit to stogaru/verify-rust-std that referenced this pull request Oct 17, 2024
Modifies the `check_cast` harness to:
- Be a proof instead of a proof for contract
- Remove the generic type parameter

Currently, Kani doesn't run this harness. (See the
[log](https://github.com/model-checking/verify-rust-std/actions/runs/10887990165/job/30211482361?pr=85)
from a recent PR). It doesn't run the harness because it has a generic
type parameter, and Kani's error handling for contract proofs doesn't
check for this condition. (PR to fix is
[here](model-checking/kani#3522)). Once we
remove the generic type parameter so that the harness runs, Kani
complains that we can't run it as a proof for contract because there are
no contracts, so we make it a regular proof instead.

By submitting this pull request, I confirm that my contribution is made
under the terms of the Apache 2.0 and MIT licenses.
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.

3 participants