|
| 1 | +# General Rules |
| 2 | + |
| 3 | +## Terms / Concepts |
| 4 | + |
| 5 | +**Verification Target:** [Our repository](https://github.com/model-checking/verify-rust-std) is a fork of the original Rust repository, |
| 6 | +and we kept a copy of the Rust standard library inside the `library/` folder that shall be used as the verification target for all our challenges. |
| 7 | +We will periodically update the `library/` folder to track newer versions of the [official Rust standard library](https://github.com/rust-lang/rust/). |
| 8 | +NOTE: This work is not officially affiliated, or endorsed by the Rust project or Rust Foundation. |
| 9 | +**Challenges:** Each challenge will be documented in the contest book in the Challenges chapter, and they will have a |
| 10 | +tracking issue where participants can add comments and ask clarification questions. |
| 11 | +You can find the list of [open challenges here](https://github.com/model-checking/verify-rust-std/labels/Challenge). |
| 12 | + |
| 13 | +**Solutions:** Solutions to a challenge should be submitted as a single Pull Request (PR) to the contest repository. |
| 14 | +The solution should run as part of the CI. |
| 15 | +See more details about [minimum requirements for each solution](general-rules.md#solution-requirements). |
| 16 | + |
| 17 | + |
| 18 | +## Basic Workflow |
| 19 | + |
| 20 | +1. A challenge will be published in the contest book with details of the challenge, |
| 21 | + and a tracking issue labeled with “Challenge” will be opened, so it can be used for clarifications and questions, |
| 22 | + as well as to track the status of the challenge. |
| 23 | +2. Participants should create a fork of the contest repository where they will implement their proposed solution. |
| 24 | +3. Once they are to submit their solution for analysis, participants should create a PR against the contest repository for analysis. |
| 25 | + Please make sure your solution meets [the minimum requirements described here](general-rules.md#solution-requirements). |
| 26 | +4. Each contribution will be reviewed on a first come, first served basis. |
| 27 | + Acceptance will be based on a unanimous affirmative vote from the review committee. |
| 28 | +5. Once approved by the review committee, the change will be merged into the repository. |
| 29 | + |
| 30 | +## Solution Requirements |
| 31 | + |
| 32 | +A proposed solution to a contest will only **be reviewed** if all the minimum requirements below are met: |
| 33 | + |
| 34 | +* Each contribution or attempt should be submitted via a pull request to be analyzed by the committee. |
| 35 | +* By submitting the solution, participants confirm that they can use, modify, copy, and redistribute their contribution, |
| 36 | + under the terms of their choice. |
| 37 | +* The contribution must be automated and should be checked and pass as part of the PR checks. |
| 38 | +* All tools used by the solution must be in [the list of accepted tools](tools.md#approved-tools), |
| 39 | + and previously integrated in the contest repository. |
| 40 | + If that is not the case, please submit a separate [tool application first](todo.md). |
| 41 | +* There is no restriction on the number of contributors for a solution. |
| 42 | + Make sure you have the rights to submit your solution and that all contributors are properly mentioned. |
| 43 | +* The solution cannot impact the runtime logic of the standard library unless the change is proposed and incorporated |
| 44 | + into the Rust standard library. |
| 45 | + |
| 46 | +Any exception to these requirements will only be considered if it is specified as part of the acceptance criteria of the |
| 47 | +challenged being solved. |
| 48 | + |
| 49 | +## Call for Challenges |
| 50 | + |
| 51 | +The goal of the contest is to enable the verification of the entire Rust standard library. |
| 52 | +The type of obstacles users face may depend on which part of the standard library you would like to verify. Thus, our challenges are developed with the target of verifying a specific section of the standard library or strengthening existing verification. |
| 53 | + |
| 54 | +Everyone is welcome to submit new challenge proposals for review by our committee. |
| 55 | +Follow the following steps to create a new proposal: |
| 56 | + |
| 57 | +1. Create a tracking issue using the Issue template [Challenge Proposal](todo.md) for your challenge. |
| 58 | +2. In your fork of this repository do the following: |
| 59 | + 1. Copy the template file (`book/src/challenge_template.md`) to `book/src/challenges/<ID_NUMBER>-<challenge-name>.md`. |
| 60 | + 2. Fill in the details according to the template instructions. |
| 61 | + 3. Add a link to the new challenge inside `book/src/SUMMARY.md` |
| 62 | + 4. Submit a pull request. |
| 63 | +3. Address any feedback in the pull request. |
| 64 | +4. If approved, we will publish your challenge and add the “Challenge” label to the tracking issue. |
| 65 | + |
| 66 | +## Tool Applications |
| 67 | + |
| 68 | +Solutions must be automated using one of the tools previously approved and listed [here](tools.md#approved-tools): |
| 69 | + |
| 70 | +* Any new tool that participants want to enable will require an application using the Issue template [Tool application](todo.md). |
| 71 | +* The tool will be analyzed by an independent committee consisting of members from the Rust open-source developers and AWS |
| 72 | +* A new tool application should clearly specify the differences to existing techniques and provide sufficient background |
| 73 | + of why this is needed. |
| 74 | +* The tool application should also include mechanisms to audit its implementation and correctness. |
| 75 | +* Once the tool is approved, the participant needs to create a PR that creates a new action that runs the |
| 76 | + std library verification using the new tool, as well as an entry to the “Approved Tools” section of this book. |
| 77 | +* Once the PR is merged, the tool is considered integrated. |
| 78 | +* The contest repository will be updated periodically, which can impact the tool capacity to analyze the new version of the repository. |
| 79 | + I.e., the action may no longer pass after an update. |
| 80 | + This will not impact the approval status of the tool, however, |
| 81 | + new solutions that want to employ the tool may need to ensure the action is passing first. |
0 commit comments