Skip to content

rustfoundation/safety-critical-rust-coding-guidelines

Repository files navigation

Safety-Critical Rust Coding Guidelines

This repository contains Coding Guidelines for writing Safety Critical Rust, developed by the Safety Critical Rust Consortium.

Building the coding guidelines

The Safety-Critical Rust Coding Guidelines website uses Sphinx and Sphinx-Needs to build a rendered version of the coding guidelines, and uv to install and manage Python dependencies (including Sphinx itself). To simplify building the rendered version, we created a script called make.py that takes care of invoking Sphinx with the right flags.

  • On Linux and macOS, build the rendered version by running ./make.py.
  • On Windows systems, build the rendered version by running uv run make.py.

By default, Sphinx uses incremental rebuilds to generate the content that changed since the last invocation. If you notice a problem with incremental rebuilds, pass the -c flag to clear the existing artifacts before building ./make.py -c.

The following output is generated:

  • A rendered version in build/html/
  • A machine-parseable artifact in build/html/needs.json
  • A record of the contents with checksums in build/html/guidelines-ids.json

Running builds offline

If you're working without internet access or want to avoid reaching out to remote resources, you can pass the --offline flag:

./make.py --offline

This prevents the build system from attempting to fetch remote resources, such as updates to the specification. Use this flag when you need reproducible or air-gapped builds.

Use --offline if you are running make.py frequently during development, to prevent rate-limiting due to repeated requests to the the FLS.

Build breaking due to out-dated spec lock file

It's a fairly common occurrence for the build to break due to an out of date spec lock file in src/spec.lock.

The file is checked against the current live version of the specification, which means that your local development may go out of date while you are developing a feature.

Continuing work while on a feature branch

If you run into this while developing a coding guideline, you may ignore this error by running the build with:

./make.py --ignore-spec-lock-diff

Auditing the difference

When the build breaks due to the difference in spec.lock, a log is saved in /tmp/fls_diff_<random>.txt which you can use to audit the differences.

To see a quick summary of the difference:

uv run python scripts/fls_audit.py --summary-only

To see a full report of the difference:

uv run python scripts/fls_audit.py

See docs/fls-audit.md for the full workflow, snapshots, advanced options, and the steps to rationalize and update src/spec.lock, including the rationalization checklist.

What we're working on

The Coding Guidelines work items board shows tickets actively being worked on, and tickets you can pick up.

Contributing

Read the CONTRIBUTING.md and REVIEWING.md for the details on contributing and reviewing guidelines.

The Rust Foundation has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.

Licenses

Rust is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0), with documentation portions covered by the Creative Commons Attribution 4.0 International license..

See LICENSE-APACHE, LICENSE-MIT, LICENSE-documentation, and COPYRIGHT for details.

You can also read more under the Foundation's intellectual property policy.

Other Policies

Read other Rust Foundation policies.

About

Coding Guidelines for Safety Critical Rust developed by the Safety Critical Rust Consortium.

Resources

Code of conduct

Contributing

Stars

Watchers

Forks

Packages