Run clippy and rustfmt

added frontend label

After discussion, here are the configuration files I use for my projects. Feel free to test, modify and ask me why I've made these choices.

rustfmt configuration file (.rustfmt.toml):

edition = "2021"
version = "Two"
required_version = "1.5.1"

# Enable features
format_code_in_doc_comments = true
normalize_doc_attributes = true
reorder_impl_items = true
wrap_comments = true

# Set the width of lines
chain_width = 90
comment_width = 132
max_width = 132
use_small_heuristics = "Max"

# Specific width
struct_lit_width=18
struct_variant_width=35

# Import handling
group_imports = "StdExternalCrate"
imports_granularity = "Module"

# Stylish choices
match_block_trailing_comma = true
overflow_delimited_expr = true

clippy configuration (inside main.rs/lib.rs):

// First: Deny everything.
#![deny(
    clippy::complexity,
    clippy::correctness,
    clippy::nursery,
    clippy::pedantic,
    clippy::perf,
    clippy::restriction,
    clippy::style,
    clippy::suspicious
)]
// Then: Allow some parts.
#![allow(
  // Depends on the crate
)]

mentioned in merge request !18 (merged)

Overview

Every clippy lint has documentation available on this website (Rust clippy 1.73).
Furthermore, each lint discussed below is linked to the relevant documentation page.

Before any major changes was made, a number of discussions had to be resolved.

To help the discussion, each of the clippy lints discussed below has been categorised in the following sections:

Consistency: Ensures that a coding style is applied consistently across the project.
Correctness: Detects code that may not behave as expected.
Dead code: Detects extra code that has no impact as not used/necessary.
Documentation: Covers documentation.
Errors: Covers error handling.
Idiom: Identifies code that can be rewritten in a more idiomatic way and usually improves readability.
Log: Covers how to log information.
Naming: Covers how to name identifiers.
Safety: Detects operations that may fail, particularly arithmetic (relevant to be discussed only after the error section).
Unsafe: Covers unsafe blocks

Unfortunately, the clippy categories don't fit well with the notion of categories that I wanted to have for discussion.

How `clippy` is enabled in the project

The file rr_frontend/.cargo/config.toml is adding rustflags to the Rust workspace.

Beware, this file is only read when cargo is invoked from the workspace itself.
This issue has been fixed by adding a new syntax to Cargo.toml in Rust 1.74, which is not available for our toolchain.

This file is currently heavy and follows the "default deny" approach (enable all lints and disable some):

Enable all lints: Enable each clippy category lint (even when not recommanded - see below).
Reasonable lints: Lints that do not require discussion, as they are sane to follow.
Require discussion: Lints that should be discussed because they can change the way the project should behave (in terms of error handling or safety guarantees we want to have).
Avoidable lints: Lints that do not require discussion, as they should NOT be followed in our context.

In the end, the lints in section 3 will be split into sections 2 (agree to follow) and 4 (do not agree to follow), and after the project will be patched, the section 2 will be removed (as all the lints will be satisfied). Also, the lints from section 1 will be set from warnings (-W) to errors (-D).

This file is also divided into sub-categories, corresponding to the clippy categories : This is a memo for later.

It is usually NOT recommended to blindly enable the clippy::restriction category (as done in section 1), as some lints contradict each other to maintain consistency in the project.
For example, one lint will disallow any use of <name>/mod.rs to ensure that <name>.rs is used, while another lint will ensure the reverse.

How to "try" a lint against the project

In this branch, cargo clippy invoked in the rr_frontend folder should not give any warning.

Removing any -A<lint> from this file will set the <lint> back to the previous setting, which is "throw error" (made by the section 1).

Then, it suffices to remove any desired line to see all the warnings generated.

Acceptable lints / Avoidable lints

Most of the acceptable lints are categorised in the "dead code" and "idiom" sections.

Most of the avoidable lints are lints that are useful for specific projects that do not correspond to RefinedRust. Most of them are not categorised because it didn't make sense to do so.

Even though I've made a pre-selection, you're welcome to check them out if they seem relevant to you: Feel free to tell me if any lints should be disallowed or allowed.