|
| 1 | +# FAQs |
| 2 | + |
| 3 | +This section collects frequently asked questions about Kani. |
| 4 | +Please consider [opening an issue](https://github.com/model-checking/kani/issues/new/choose) if you have a question that would like to see here. |
| 5 | + |
| 6 | +## Questions |
| 7 | + |
| 8 | +<details> |
| 9 | +<summary>Kani doesn't fail after <code>kani::assume(false)</code>. Why?</summary> |
| 10 | +</br> |
| 11 | + |
| 12 | +`kani::assume(false)` (or `kani::assume(cond)` where `cond` is a condition that results in `false` in the context of the program), won't cause errors in Kani. |
| 13 | +Instead, such an assumption has the effect of blocking all the symbolic execution paths from the assumption. |
| 14 | +Therefore, all checks after the assumption should appear as [`UNREACHABLE`](#../../verification-results.md). |
| 15 | +That's the expected behavior for `kani::assume(false)` in Kani. |
| 16 | + |
| 17 | +If you didn't expect certain checks in a harness to be `UNREACHABLE`, we recommend using the [`kani::cover` macro](#../../verification-results.md#cover-property-results) to determine what conditions are possible in case you've over-constrained the harness. |
| 18 | +</details> |
| 19 | + |
| 20 | +<details> |
| 21 | +<summary>I implemented the <code>kani::Arbitrary</code> trait for a type that's not from my crate, and got the error |
| 22 | +<code>only traits defined in the current crate can be implemented for types defined outside of the crate</code>. |
| 23 | +What does this mean? What can I do?</summary> |
| 24 | +</br> |
| 25 | + |
| 26 | +This error is due to a violation of Rust's orphan rules for trait implementations, which are explained [here](https://doc.rust-lang.org/error_codes/E0117.html). |
| 27 | +In that case, you'll need to write a function that builds an object from non-deterministic variables. |
| 28 | +Inside this function you would simply return an arbitrary value by generating arbitrary values for its components. |
| 29 | + |
| 30 | +For example, let's assume the type you're working with is this enum: |
| 31 | + |
| 32 | +```rust |
| 33 | +#[derive(Copy, Clone)] |
| 34 | +pub enum Rating { |
| 35 | + One, |
| 36 | + Two, |
| 37 | + Three, |
| 38 | +} |
| 39 | +``` |
| 40 | + |
| 41 | +Then, you can match on a non-deterministic integer (supplied by `kani::any`) to return non-deterministic `Rating` variants: |
| 42 | + |
| 43 | +```rust |
| 44 | + pub fn any_rating() -> Rating { |
| 45 | + match kani::any() { |
| 46 | + 0 => Rating::One, |
| 47 | + 1 => Rating::Two, |
| 48 | + _ => Rating::Three, |
| 49 | + } |
| 50 | + } |
| 51 | +``` |
| 52 | + |
| 53 | +More details about this option, which also useful in other cases, can be found [here](https://model-checking.github.io/kani/tutorial-nondeterministic-variables.html#custom-nondeterministic-types). |
| 54 | + |
| 55 | +If the type comes from `std` (Rust's standard library), you can [open a request](https://github.com/model-checking/kani/issues/new?assignees=&labels=%5BC%5D+Feature+%2F+Enhancement&template=feature_request.md&title=) for adding `Arbitrary` implementations to the Kani library. |
| 56 | +Otherwise, there are more involved options to consider: |
| 57 | + 1. Importing a copy of the external crate that defines the type, then implement `Arbitrary` there. |
| 58 | + 2. Contributing the `Arbitrary` implementation to the external crate that defines the type. |
| 59 | +</details> |
0 commit comments