Skip to content

Commit e53ed63

Browse files
authored
Docs: Add an FAQ section (rust-lang#2250)
1 parent 4b504b2 commit e53ed63

File tree

2 files changed

+63
-0
lines changed

2 files changed

+63
-0
lines changed

docs/src/SUMMARY.md

+4
Original file line numberDiff line numberDiff line change
@@ -40,3 +40,7 @@
4040
- [Overrides](./overrides.md)
4141

4242
- [Crates Documentation](./crates/index.md)
43+
44+
---
45+
46+
- [FAQ](./faq.md)

docs/src/faq.md

+59
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
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

Comments
 (0)