Skip to content

Commit

Permalink
Merge branch 'main' into layout-contracts
Browse files Browse the repository at this point in the history
  • Loading branch information
tautschnig authored Jul 10, 2024
2 parents 2e9f3f6 + bbfbb19 commit e310ede
Show file tree
Hide file tree
Showing 3 changed files with 207 additions and 0 deletions.
156 changes: 156 additions & 0 deletions .github/workflows/pr_approval.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,156 @@
name: Check PR Approvals

# For now, the workflow gets triggered only when a review is submitted
# This technically means, a PR with zero approvals can be merged by the rules of this workflow alone
# To protect against that scenario, we can turn on number of approvals required to 2 in the github settings
# of the repository
on:
pull_request_review:
types: [submitted]
workflow_dispatch:

jobs:
check-approvals:
if: github.event.review.state == 'APPROVED' || github.event_name == 'workflow_dispatch'
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v2

- name: Install TOML parser
run: npm install @iarna/toml

- name: Check PR Relevance and Approvals
uses: actions/github-script@v6
with:
script: |
const fs = require('fs');
const toml = require('@iarna/toml');
const { owner, repo } = context.repo;
let pull_number;
if (github.event_name === 'workflow_dispatch') {
const branch = github.ref.replace('refs/heads/', '');
const prs = await github.rest.pulls.list({
owner,
repo,
head: `${owner}:${branch}`,
state: 'open'
});
if (prs.data.length === 0) {
console.log('No open PR found for this branch.');
return;
}
pull_number = prs.data[0].number;
} else {
pull_number = context.issue.number;
}
// Get PR files
const files = await github.rest.pulls.listFiles({
owner,
repo,
pull_number
});
const relevantPaths = ['library/', 'doc/src/challenges/'];
const isRelevantPR = files.data.some(file =>
relevantPaths.some(path => file.filename.startsWith(path))
);
if (!isRelevantPR) {
console.log('PR does not touch relevant paths. Exiting workflow.');
return;
}
// Get parsed data
try {
const tomlContent = fs.readFileSync('.github/pull_requests.toml', 'utf8');
console.log('TOML content:', tomlContent);
const tomlData = toml.parse(tomlContent);
console.log('Parsed TOML data:', JSON.stringify(tomlData, null, 2));
if (!tomlData.committee || !Array.isArray(tomlData.committee.members)) {
throw new Error('committee.members is not an array in the TOML file');
}
requiredApprovers = tomlData.committee.members;
} catch (error) {
console.error('Error reading or parsing TOML file:', error);
core.setFailed('Failed to read required approvers list');
return;
}
// Get all reviews
const reviews = await github.rest.pulls.listReviews({
owner,
repo,
pull_number
});
// Example: approvers = ["celina", "zyad"]
const approvers = new Set(
reviews.data
.filter(review => review.state === 'APPROVED')
.map(review => review.user.login)
);
const requiredApprovals = 2;
const requiredApproversCount = Array.from(approvers)
.filter(approver => requiredApprovers.includes(approver))
.length;
// TODO: Improve logging and messaging to the user
console.log('PR Approvers:', Array.from(approvers));
console.log('Required Approvers:', requiredApproversCount);
// Core logic that checks if the approvers are in the committee
const checkName = 'PR Approval Status';
const conclusion = (approvers.size >= requiredApprovals && requiredApproversCount >= 2) ? 'success' : 'failure';
const output = {
title: checkName,
summary: `PR has ${approvers.size} total approvals and ${requiredApproversCount} required approvals.`,
text: `Approvers: ${Array.from(approvers).join(', ')}\nRequired Approvers: ${requiredApprovers.join(', ')}`
};
// Get PR details
const pr = await github.rest.pulls.get({
owner,
repo,
pull_number
});
// Create or update check run
const checkRuns = await github.rest.checks.listForRef({
owner,
repo,
ref: pr.data.head.sha,
check_name: checkName
});
// Reuse the same workflow everytime there's a new review submitted
// instead of creating new workflows. Better efficiency and readability
// as the number of workflows is kept to a minimal number
if (checkRuns.data.total_count > 0) {
await github.rest.checks.update({
owner,
repo,
check_run_id: checkRuns.data.check_runs[0].id,
status: 'completed',
conclusion,
output
});
} else {
await github.rest.checks.create({
owner,
repo,
name: checkName,
head_sha: pr.data.head.sha,
status: 'completed',
conclusion,
output
});
}
if (conclusion === 'failure') {
core.setFailed(`PR needs at least ${requiredApprovals} total approvals and 2 required approvals. Current approvals: ${approvers.size}, Required approvals: ${requiredApproversCount}`);
}
1 change: 1 addition & 0 deletions doc/src/SUMMARY.md
Original file line number Diff line number Diff line change
Expand Up @@ -16,3 +16,4 @@
- [Core Transmutation](./challenges/0001-core-transmutation.md)
- [Memory safety of core intrinsics](./challenges/0002-intrinsics-memory.md)
- [Pointer Arithmetic](./challenges/0003-pointer-arithmentic.md)
- [Inductive data type](./challenges/0005-linked-list.md)
50 changes: 50 additions & 0 deletions doc/src/challenges/0005-linked-list.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Challenge 5: Verify functions iterating over inductive data type: `linked_list`

- **Status:** Open
- **Tracking Issue:** [Link to issue](https://github.com/model-checking/verify-rust-std/issues/29)
- **Start date:** *24/07/01*
- **End date:** *24/12/10*

-------------------


## Goal

Verify the memory safety of [`alloc::collections::linked_list` functions](https://github.com/rust-lang/rust/blob/c290e9de32e8ba6a673ef125fde40eadd395d170/library/alloc/src/collections/linked_list.rs) that iterate the its internal inductive-defined data type.

### Details

The internal representations of `linked_list` are bi-direction linked list nodes. To unboundedly prove the memory safety of functions that iterating over such inductive-defined data type, we need to illustrate the memory safety for linked lists of arbitrary shape. On the other hand, if we can only prove the memory safety for certain shapes of linked lists, how should we specify the precondition---the assumptions on the shape of the inductive-defined data type---of such functions.


### Success Criteria

The memory safety of the following public functions that iterating over the internal inductive data type must be verified:

| Function | Location |
|---------|---------|
|clearn | alloc::collections::linked_list |
|contains| alloc::collections::linked_list |
|split_off| alloc::collections::linked_list |
|remove| alloc::collections::linked_list |
|retain| alloc::collections::linked_list |
|retain_mut| alloc::collections::linked_list |
|extract_if| alloc::collections::linked_list |


The verification must be unbounded---it must hold for linked lists of arbitrary shape.

It is OK to assume that the generic type `T` of the proofs is primitive types, e.g., `i32`, `u32`, `bool`, etc.

### List of UBs

All proofs must automatically ensure the absence of the following undefined behaviors [ref](https://github.com/rust-lang/reference/blob/142b2ed77d33f37a9973772bd95e6144ed9dce43/src/behavior-considered-undefined.md):

* Accessing (loading from or storing to) a place that is dangling or based on a misaligned pointer.
* Reading from uninitialized memory except for padding or unions.
* Mutating immutable bytes.
* Producing an invalid value


Note: All solutions to verification challenges need to satisfy the criteria established in the [challenge book](../general-rules.md)
in addition to the ones listed above.

0 comments on commit e310ede

Please sign in to comment.