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

Documentation: Structural changes #969

Merged
merged 6 commits into from
Mar 24, 2022

Conversation

adpaco-aws
Copy link
Contributor

@adpaco-aws adpaco-aws commented Mar 21, 2022

Description of changes:

Basically re-organizes the main chapters of the Kani documentation by grouping them into a few parts, which I think achieves a cleaner look and makes it easier to find information a particular topics. Reviews a few section names and moves files accordingly.

The left bar now looks like this:

Resolved issues:

Part of #700
Creates #966, #967 and #968
Screen Shot 2022-03-23 at 18 51 29

Call-outs:

There may be more changes coming to the overall structure but this contribution brings us a step closer to it.

Testing:

  • How is this change tested? Running mdbook locally.

  • Is this a refactor change? No.

Checklist

  • Each commit message has a non-empty body, explaining why the change was made
  • Methods or procedures are documented
  • Regression or unit tests are included, or existing tests cover the modified code
  • My PR is restricted to a single feature or bugfix

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

@adpaco-aws adpaco-aws requested a review from a team as a code owner March 21, 2022 18:19

- [Limitations](./limitations.md)
- [Comparison with other tools](./tool-comparison.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO this belongs with "getting started," the purpose is mostly to answer what Kani is and why people should be interested.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think of "getting started" as a section that you can read in a few minutes to get a quick understanding of the project. The comparison with other tools goes a bit deeper somehow and is linked in many sections around (including the introduction). In my opinion, this is an article that will be read by people who want to know more, but right after "Introduction" may cause potential users lose interest.

- [Debugging failures]()
- [Debugging non-termination]()
- [Debugging coverage]()
- [Usage](./usage.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see the need for this page, or putting the below in a sublist.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think splitting into subsections here (and in the next case) provides a much cleaner and organized look to our documentation. In my opinion, the previous version was a little "too flat", so adding subsections where we can may help with readability and navigation.

# Developer documentation
- [Command cheat sheets](./cheat-sheets.md)
- [Working with `rustc`](./rustc-hacks.md)
- [Testing](./testing.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I similarly don't think this page and nesting is adding anything here

* [On a single file](./kani-single-file.md) with the `kani` command.
* [On a package](./cargo-kani.md) with the `cargo-kani` command.

Running [Kani on a single file](./kani-single-file.md) is quite useful for small examples.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or projects that don't use cargo... like Rust for Linux. :)

* [On a single file](./kani-single-file.md) with the `kani` command.
* [On a package](./cargo-kani.md) with the `cargo-kani` command.

Running [Kani on a single file](./kani-single-file.md) is quite useful for small examples.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or projects that don't use cargo... like Rust for Linux. :)

However, if you plan to integrate Kani in your projects, the recommended
approach is to use [Kani on a package](./cargo-kani.md) because it includes
utilities for tagging, extracting and running all proof harnesses in your
package without making changes to its codebase.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me which changes users would have to make to their codebase. I would say that the main difference today between kani and cargo kani is the ability to handle external dependencies.

However, if you plan to integrate Kani in your projects, the recommended
approach is to use [Kani on a package](./cargo-kani.md) because it includes
utilities for tagging, extracting and running all proof harnesses in your
package without making changes to its codebase.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not clear to me which changes users would have to make to their codebase. I would say that the main difference today between kani and cargo kani is the ability to handle external dependencies.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, the ability to build more than a single .rs file at all. I don't think kani is even useful for customers, really.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are able to verify a full crate with standalone kani, independent on the number of files, as long as it doesn't have any external dependency.

For example, you can verify the rectangle example inside tests/cargo-kani/rectangle-example with the following command:

kani src/lib.rs --function stretched_rectangle_can_hold_original

Note that the crate has two files: src/lib.rs and src/rectangle.rs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh neat. TIL

Copy link
Contributor Author

@adpaco-aws adpaco-aws Mar 23, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh neat. TIL

+1

Let's just write that then, no?

However, if you plan to integrate Kani in your projects, the recommended
approach is to use [Kani on a package](./cargo-kani.md) because of its ability
to handle external dependencies.

@adpaco-aws
Copy link
Contributor Author

Updated with feedback from PR and discussion.

Copy link
Contributor

@zhassan-aws zhassan-aws left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM


- [Limitations](./limitations.md)
- [Limitations](./rust-feature-support.md)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be called "Rust feature support"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed it, although it is likely that I write a main "Limitations" section when I review this part later.

@adpaco-aws adpaco-aws merged commit 37bd70f into model-checking:main Mar 24, 2022
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 22, 2022
* Documentation: Structural changes

* Rename "Verification results" examples

* Revert some changes

* Add suggestions on usage

* Rename: "Limitations"->"Rust feature support"

* Undo example path renaming to introduction
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 25, 2022
* Documentation: Structural changes

* Rename "Verification results" examples

* Revert some changes

* Add suggestions on usage

* Rename: "Limitations"->"Rust feature support"

* Undo example path renaming to introduction
tedinski pushed a commit to tedinski/rmc that referenced this pull request Apr 26, 2022
* Documentation: Structural changes

* Rename "Verification results" examples

* Revert some changes

* Add suggestions on usage

* Rename: "Limitations"->"Rust feature support"

* Undo example path renaming to introduction
tedinski pushed a commit that referenced this pull request Apr 27, 2022
* Documentation: Structural changes

* Rename "Verification results" examples

* Revert some changes

* Add suggestions on usage

* Rename: "Limitations"->"Rust feature support"

* Undo example path renaming to introduction
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.

4 participants