-
Notifications
You must be signed in to change notification settings - Fork 16
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
DOC-433 | Added solana cli options #335
base: solana/docs_template
Are you sure you want to change the base?
DOC-433 | Added solana cli options #335
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly good - minor nits. Thanks.
@phreppo can you please add information about the missing parts where Yoav requested Jorge's support, I believe you should be familiar with the flags that miss explanations?
The build script must output the following: | ||
|
||
- `project_directory`: Path to the project root directory. | ||
- `sources`: List of files or directories used or imported in the program. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can this list contain a regular expression? Or does the user need to list all files explicitly?
- `sources`: List of files or directories used or imported in the program. | |
- `sources`: List of source files or directories used or imported in the program. All files declared in this list will be uploaded as sources to cloud and displayed in the rule report. Source files are required, for instance, for the jump to source feature to work. |
Modes of Operation | ||
------------------ | ||
|
||
The Certora Solana Prover has two modes of operation. These modes are mutually exclusive - you cannot run the tool with more than one mode at a time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the two modes of operations here?
Are you referring to --build_script
and precompiled binary
here? That's not clear to me - state them explicitly?
|
||
These files are in [JSON5](https://json5.org/) format and use a `.conf` extension. They hold the parameters and options for the Prover. | ||
|
||
For more details, see `Conf File <https://docs.certora.com/en/latest/docs/prover/cli/conf-file-api.html#conf-files>`_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For more details, see `Conf File <https://docs.certora.com/en/latest/docs/prover/cli/conf-file-api.html#conf-files>`_ | |
For more details, see `Conf File <https://docs.certora.com/en/latest/docs/prover/cli/conf-file-api.html#conf-files>`. |
This option saves a lot of run time. Use it whenever you care about only a | ||
specific subset of a specification's properties. The most common case is when | ||
This option saves runtime and is useful for verifying specific subsets of a specification. Common cases include testing new rules or investigating specific failures. | ||
you add a new rule to an existing specification. The other is when code changes | ||
cause a specific rule to fail; in the process of fixing the code, updating the | ||
rule, and understanding counterexamples, you likely want to verify only that | ||
specific rule. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's sufficient to just write:
This option saves a lot of run time. Use it whenever you care about only a | |
specific subset of a specification's properties. The most common case is when | |
This option saves runtime and is useful for verifying specific subsets of a specification. Common cases include testing new rules or investigating specific failures. | |
you add a new rule to an existing specification. The other is when code changes | |
cause a specific rule to fail; in the process of fixing the code, updating the | |
rule, and understanding counterexamples, you likely want to verify only that | |
specific rule. | |
This option saves a lot of run time as it only executes a specific rule. This option saves runtime and is useful for verifying specific subsets of a specification. Common cases include testing new rules or investigating specific failures. |
|
||
**What does it do?** | ||
|
||
Adds a description message to your run, similar to a commit message. This message appears in the title of the completion email. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The message is more important in the prover dashboard / rule report. I think we should rather state this here.
Adds a description message to your run, similar to a commit message. This message appears in the title of the completion email. | |
Adds a description message to your run, similar to a commit message. This message appears on the Prover dashboard and in the rule report. |
|
||
**When to use it?** | ||
|
||
TODO: @Jorge please advise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phreppo can you add a few words on the usage of it?
|
||
**When to use it?** | ||
|
||
TODO: @Jorge please advise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phreppo can you add a few words on the usage of it?
|
||
**When to use it?** | ||
|
||
TODO: @Jorge please advise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@phreppo are you familiar with this, can you add a few words on the usage of it?
|
||
**What does it do?** | ||
|
||
Runs formal verification of specified properties while providing an automatic method to compile a Rust project. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be wrong here, but I thought that the build script is the Python script that builds the project without running the formal verification.
Am I wrong?
**What does it do?** | ||
|
||
Provides the prover with a whitespace-separated list of extra features passed to the build script. | ||
|
||
**When to use it?** | ||
|
||
TODO: @Jorge please advise. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
**What does it do?** | |
Provides the prover with a whitespace-separated list of extra features passed to the build script. | |
**When to use it?** | |
TODO: @Jorge please advise. | |
**What does it do?** | |
Provides the prover with a whitespace-separated list of extra `Cargo features <https://doc.rust-lang.org/cargo/reference/features.html>` passed to the build script. | |
These features are then passed to ``cargo`` to build the project. | |
**When to use it?** | |
Use it when there is a need to enable a specific `Cargo feature <https://doc.rust-lang.org/cargo/reference/features.html>` to compile the source code. |
Naming convention:
Before requesting review:
spelling_wordlist.txt
README.md
for information about style and markdown syntaxJira ticket: https://certora.atlassian.net/browse/CERT-7992
Link to generated documentation: TODO