RFC for List Subcommand #3463
RFC for List Subcommand #3463
Conversation
There was a problem hiding this comment.
I would recommend to simplify the human output and the implementation. For the json format, we should include a more detailed output, including the function location (file, line, column) to help users / VSCode extension to retrieve any extra information.
BTW, I haven't seen any information on the json format / versioning. Can you please include this here? Thanks!
|
Thanks for the feedback @celinval! Addressed your comments. |
There was a problem hiding this comment.
I would say, the RFC is missing one small section on the schema/fields that will be presented to the user via "human"/"pretty" or "json". I can see through the examples what fields they show but its not clear if that's an exhaustive list or if some of these fields are optional etc.
If possible, can you add a section that is essentially formalizing the fields that a user can expect? Maybe something like this with JSON types for the JSON and the json version used as well
### Output Schema
1. Kani Version: Int
2. Standard Harnesses: List[] | None.
2.1 function: string
2.2 file: string
4. Contract Harnesses: List[] | None
...
| For example: | ||
|
|
||
| ``` | ||
| Kani Version: 0.5.4 |
|
|
||
| ## User Experience | ||
|
|
||
| Users run a `list` subcommand, which prints metadata about the harnesses and contracts in each crate under verification. The subcommand will take the option `--message-format=[human|json]`, which changes the output format. The default is `human`, which prints to the terminal. The `json` option creates and writes to a JSON file instead. |
There was a problem hiding this comment.
I personally prefer pretty or report as the variant of the format, over human, i.e the options should be format=[pretty | json] or [report | json]. I don't know human is a recognized output format in other tools, but there usually is a pretty mode which is close to what we are going to present.
Not a blocker and this is something we can change later, but it's better to get the right names from the beginning.
|
|
||
| This subcommand will not fail. In the case that it does not find any harnesses or contracts, it will print a message informing the user of that fact. | ||
|
|
||
| ### Human Format |
There was a problem hiding this comment.
Above comment applies here as well, unsure about the word human itself.
These are the auto-generated release notes: ## What's Changed * Update CBMC build instructions for Amazon Linux 2 by @tautschnig in #3431 * Handle intrinsics systematically by @artemagvanian in #3422 * Bump tests/perf/s2n-quic from `445f73b` to `ab9723a` by @dependabot in #3434 * Automatic cargo update to 2024-08-12 by @github-actions in #3433 * Actually apply CBMC patch by @tautschnig in #3436 * Update features/verify-rust-std branch by @feliperodri in #3435 * Add test related to issue 3432 by @celinval in #3439 * Implement memory initialization state copy functionality by @artemagvanian in #3350 * Bump tests/perf/s2n-quic from `ab9723a` to `80b93a7` by @dependabot in #3453 * Make points-to analysis handle all intrinsics explicitly by @artemagvanian in #3452 * Automatic cargo update to 2024-08-19 by @github-actions in #3450 * Add loop scanner to tool-scanner by @qinheping in #3443 * Avoid corner-cases by grouping instrumentation into basic blocks and using backward iteration by @artemagvanian in #3438 * Re-enabled hierarchical logs in the compiler by @celinval in #3449 * Fix ICE due to mishandling of Aggregate rvalue for raw pointers to `str` by @celinval in #3448 * Automatic cargo update to 2024-08-26 by @github-actions in #3459 * Bump tests/perf/s2n-quic from `80b93a7` to `8f7c04b` by @dependabot in #3460 * Update deny action by @zhassan-aws in #3461 * Basic support for memory initialization checks for unions by @artemagvanian in #3444 * Adjust test patterns so as not to check for trivial properties by @tautschnig in #3464 * Clarify comment in RFC Template by @carolynzech in #3462 * RFC: Source-based code coverage by @adpaco-aws in #3143 * Adopt Rust's source-based code coverage instrumentation by @adpaco-aws in #3119 * Upgrade toolchain to 08/28 by @jaisnan in #3454 * Extra tests and bug fixes to the delayed UB instrumentation by @artemagvanian in #3419 * Upgrade Toolchain to 8/29 by @carolynzech in #3468 * Automatic toolchain upgrade to nightly-2024-08-30 by @github-actions in #3469 * Extend name resolution to support qualified paths (Partial Fix) by @celinval in #3457 * Partially integrate uninit memory checks into `verify_std` by @artemagvanian in #3470 * Update Toolchain to 9/1 by @carolynzech in #3478 * Automatic cargo update to 2024-09-02 by @github-actions in #3480 * Bump tests/perf/s2n-quic from `8f7c04b` to `1ff3a9c` by @dependabot in #3481 * Automatic toolchain upgrade to nightly-2024-09-02 by @github-actions in #3479 * Automatic toolchain upgrade to nightly-2024-09-03 by @github-actions in #3482 * RFC for List Subcommand by @carolynzech in #3463 * Add tests for fixed issues. by @carolynzech in #3484 **Full Changelog**: kani-0.54.0...kani-0.55.0 By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.
RFC for the
kani listsubcommand.I saw the comment in the template to leave the Software Design section empty, but I was looking at the raw MD file and made the mistake of thinking it referred to all sections below the comment. In other words, I thought when it said "We recommend you to leave this empty for the first version of your RFC" it meant that everything below the comment should be empty (so Rationale, Open Questions, and Future Work) and not Software Design. I realized my mistake when I was making this PR, but I figured I may as well leave it since I already wrote it. I opened a PR to update the comment.
Resolves #2573, #1612.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.