perfectionist lints

perfectionist::arc_rc_clone↑ top

enabledcalling .clone() on an Arc<T> or Rc<T>; prefer the qualified Arc::clone / Rc::clone form

What it does

Flags value.clone() where value is an Arc<T> or Rc<T>, and suggests rewriting it as the qualified Arc::clone(...) / Rc::clone(...) form. For a receiver of type Arc<T> / Rc<T>, the rewrite is Arc::clone(&value); for a receiver already typed as &Arc<T> / &Rc<T>, the leading & is dropped (Arc::clone(value)) so the result doesn't form a stutter-borrow &&Arc<T>.

The qualified form is accepted in every shape: the bare Arc::clone(...), the turbofish-typed Arc::<T>::clone(...), and the UFCS <Arc<T> as Clone>::clone(...) are all left untouched. The lint targets only the method-call shape, which reads as a generic Clone call rather than the cheap refcount bump it actually is.

Why restrict this?

This is a stylistic preference, not a correctness issue. Arc<T> and Rc<T> implement Clone precisely so the method call compiles; the practice forbidden here is the method-call dispatch (value.clone()), where the impl Rust picks depends on the receiver's type. The accepted qualified forms — bare (Arc::clone(&value)), turbofish (Arc::<T>::clone(&value)), and UFCS (<Arc<T> as Clone>::clone(&value)) — all name the impl at the call site, so the cost is visible to the reader. Two reasons to prefer them:

• Explicit cost. Arc::clone is O(1) reference-count bump regardless of what T is; T::clone may be an arbitrarily expensive deep copy. If the binding's type later changes from Arc<Vec<u8>> to &Vec<u8>, the method-call form value.clone() silently switches to <Vec<u8> as Clone>::clone and starts allocating; the qualified form does not type check and fails loudly.
• Reader signal. Arc::clone(&handle) reads as "share a handle"; handle.clone() reads as a generic Clone invocation whose cost is unknown without checking the binding's type.

Example

fn spawn_worker(state: std::sync::Arc<State>) {
    let copy = state.clone();
    thread::spawn(move || work(copy));
}

Use instead:

fn spawn_worker(state: std::sync::Arc<State>) {
    let copy = std::sync::Arc::clone(&state);
    thread::spawn(move || work(copy));
}

Configuration: none.

Source: src/rules/arc_rc_clone.rs

perfectionist::derive_ordering↑ top

disabledtrait names in a #[derive(...)] list are not in the configured order

What it does

Enforces a project-wide ordering of trait names inside a single #[derive(...)] list. Two styles are configurable via style:

• alphabetical (default) — every trait name must be in ASCII-case-insensitive alphabetical order.
• prefix_then_alphabetical — the configured prefix list of traits goes first, in the listed order; remaining traits are sorted alphabetically after.

Trait matching is by the final path segment, so serde::Deserialize is matched as Deserialize. The lint does not police how derives are partitioned across multiple #[derive(...)] lines — that's a layout decision left to the author.

Why restrict this?

This is a stylistic preference, not a correctness issue. The trait order inside #[derive(...)] has no semantic effect: #[derive(Debug, Clone)] and #[derive(Clone, Debug)] produce identical impls. A project-wide convention makes derive lists scan uniformly across the codebase. cargo fmt does not reorder derives, so this lint is the only mechanism for enforcing one.

The opinion is opt-in: a project that doesn't want to commit to a single ordering shouldn't have to set anything. The rule therefore ships disabled by default — enable it per crate by adding to dylint.toml:

[perfectionist]
enable = ["derive_ordering"]

Example

Under style = "alphabetical":

#[derive(Debug, Clone, Copy)]
struct Point;

Use instead:

#[derive(Clone, Copy, Debug)]
struct Point;

Source: src/rules/derive_ordering.rs

perfectionist::flat_module_pattern↑ top

enabledsubmodule defined as module/mod.rs; prefer the flat module.rs layout

What it does

Forbids the module/mod.rs layout for submodules. Each submodule should be defined by a sibling file named after the module (module.rs), with any nested children placed inside the module/ directory next to it.

Why restrict this?

This is a stylistic preference, not a correctness issue. The flat layout keeps the file name unique to its module, so editors, terminal tabs, and grep results identify the module without their parent directory. The mod.rs form produces dozens of identically-named tabs in editors that don't disambiguate by directory.

Example

// Bad
src/foo/mod.rs

// Good
src/foo.rs
src/foo/bar.rs

Configuration: none.

Source: src/rules/flat_module_pattern.rs

perfectionist::macro_argument_binding↑ top

enabledmacro invocation passes an impure expression that should be bound to a let first

What it does

Flags impure expressions passed as top-level arguments to a function-like (name!(...)) or array-like (name![...]) macro invocation. The fix is to bind the expression to a let first and pass the binding instead, guaranteeing exactly-once evaluation.

Curly-brace invocations (name! { ... }) are out of scope: by convention they are DSL bodies (thread_local! { ... }, quote! { ... }, html! { ... }) where the evaluation contract is the macro's, not the call site's.

Why is this bad?

A function-like or array-like macro may evaluate any top-level argument zero, one, or many times depending on its matcher. Functions guarantee exactly-once evaluation per argument; macros do not, even when the call shape looks identical. The classic case is debug_assert_eq!:

debug_assert_eq!(map.insert(key, value), None, "duplicate");

In debug builds the call runs and the assertion holds. In release builds debug_assertions is off, the body folds to if false { ... }, and the argument expressions are not evaluated — insert never runs and the map ends the function in a state the author did not intend. The bug only surfaces under --release.

The same trap covers any macro that expands its capture more than once (min!/max!-style, retry loops): a side-effecting expression repeated produces wrong results.

Terminology

In this rule, pure means safe for the surrounding macro to drop or duplicate: evaluating the argument zero, one, or many times is observationally equivalent. Impure is anything else, and is what the rule flags.

The classification is syntactic: the rule recognises a curated set of shapes known to satisfy the property and treats everything else as impure. A const fn call, a Result::map chain over a pure base, or vec.fold(...) is therefore impure under this rule unless its shape is recognised — the lint cannot prove side-effect-freedom in general, only spot it. The trade-off favours flagging side-effect-free expressions over silently passing a real hazard. The set is narrower than the functional-programming notion of purity and is keyed to what a macro can actually do with its captures, not to side-effect-freedom in the abstract.

The recognised pure shapes are: literals, paths, field accesses, indexing of pure bases, dereferences, references, casts, the unit literal (), parenthesised / tuple / array-literal / array-repeat groups whose elements are all pure, binary chains of pure operands joined by side-effect-free operators, zero-arg method calls whose name is in the curated pure-getter set (len, is_empty, as_str, as_bytes, as_ref, as_mut, as_deref, as_slice, plus anything in extra_pure_methods), and calls to core / std macros whose expansion is a compile- time constant (concat!, env!, option_env!, include_str!, include_bytes!, stringify!, cfg!, line!, column!, file!, module_path!, plus anything in extra_pure_macros). A comparison like vec.len() <= cap evaluates the same way regardless of how many times the macro touches it, so binding it to a let would only force the comparison to run in release builds for no benefit; the same logic applies to env!("HOME") inside debug_assert_eq!(...) — there is nothing to evaluate at runtime.

Example

debug_assert_eq!(map.insert(key, value), None, "duplicate");

Use instead:

let ejected = map.insert(key, value);
debug_assert_eq!(ejected, None, "duplicate");

Source: src/rules/macro_argument_binding.rs

perfectionist::macro_trailing_comma↑ top

enabledmacro invocation does not follow rustfmt's vertical trailing-comma policy

What it does

For function-like macro invocations whose top-level arguments are comma-separated, enforces rustfmt's trailing_comma = "Vertical" policy that rustfmt itself does not apply inside macro bodies: multi-line invocations must end with a trailing comma; single-line invocations must not.

Eligibility is name-based — a curated list of core / std and well-known third-party macros (vec!, format!, println!, assert_eq!, dbg!, log::info!, tracing::debug!, anyhow::bail!, maplit::hashmap!, …), extended via name_based_extra and overridden via ignore.

Attribute-style invocations (#[derive(...)], #[serde(...)], etc.) are out of scope.

Why restrict this?

This is a stylistic preference, not a correctness issue. rustfmt's default trailing_comma = "Vertical" policy keeps argument lists uniform: every multi-line list ends with a comma, every single-line list does not. rustfmt opts out of macro bodies because a macro matcher can make the trailing comma load-bearing; for the curated macros covered by this lint, it cannot, and the policy applies without risk.

Multi-line invocations whose first top-level token starts on the opening-delimiter line (visual-indent / compact layout, e.g. vec![Inner { ... }]) are skipped: rustfmt's Vertical policy only adds a trailing comma when each top-level item is on its own line, separate from the delimiter, and strips any comma added to the compact shape. The two tools have to agree.

Example

let xs = vec![
    1,
    2,
    3
];
let ys = vec![1, 2, 3,];

Use instead:

let xs = vec![
    1,
    2,
    3,
];
let ys = vec![1, 2, 3];

Source: src/rules/macro_trailing_comma.rs

perfectionist::non_exhaustive_error↑ top

disablederror-shaped type is missing #[non_exhaustive]

What it does

Flags publicly-exposed error enums that lack a #[non_exhaustive] attribute. An enum is treated as an error enum when its name ends in Error (configurable) or it implements std::error::Error. Publicly-exposed sum-like structs (a single field whose type is itself an enum) follow the same rule.

"Publicly-exposed" defaults to pub items; pub(crate) and the whole-crate "every item" sweep are configurable.

Why restrict this?

This is a stylistic preference, not a correctness issue. Adding a variant to an error enum is one of the most common reasons to publish a new minor version of an error-producing library, and #[non_exhaustive] is the standard way to make that addition not a SemVer break for downstream pattern matches. Applying it up front means future variants land without a coordinated major release across the dependents that exhaustively match on the enum.

The opinion is opt-in: some projects deliberately use exhaustive error enums to force downstream consumers to handle every new variant, and binary crates have no SemVer surface to protect. The rule therefore ships disabled by default — enable it per crate by adding to dylint.toml:

[perfectionist]
enable = ["non_exhaustive_error"]

Example

#[derive(Debug)]
pub enum RuntimeError {
    SerializationFailure,
}

Use instead:

#[derive(Debug)]
#[non_exhaustive]
pub enum RuntimeError {
    SerializationFailure,
}

Source: src/rules/non_exhaustive_error.rs

perfectionist::prefer_raw_string↑ top

enabledstring literal contains only raw-expressible escapes; prefer the raw-string form

What it does

Forbids regular string literals whose only backslash escapes are ones a raw string would express verbatim — \", \\, and \'. The autofix rewrites the literal to the raw form r"..." / r#"..."#, picking the smallest hash count that avoids a delimiter collision.

This includes literals passed as arguments to macros such as println!, format!, vec!, and assert!. Suppress per call site with #[allow(perfectionist::prefer_raw_string)] when the regular form is deliberately preferred.

Pattern-position literals (e.g. match s { "C:\\path" => ... }) are out of scope — the rule only visits expression literals.

Whitespace and control-character escapes (\n, \t, \r, \0) and Unicode escapes (\x.., \u{..}) are exempt — a raw string cannot express them, and the regular form is the only choice. A literal that mixes eliminable and inexpressible escapes is also left alone; the rewrite would force the author to split the literal or fall back to concat!, which loses more than it gains.

Why restrict this?

This is a stylistic preference, not a correctness issue. The rule trades one noise source (interior backslash escapes) for a slightly more elaborate string syntax. The benefit is highest in strings full of file paths, regex patterns, JSON snippets, or embedded source code — all of which would otherwise be a sea of \\ and \".

Example

let json = "{\"name\":\"foo\"}";
let path = "C:\\Users\\foo\\bar";

Use instead:

let json = r#"{"name":"foo"}"#;
let path = r"C:\Users\foo\bar";

Source: src/rules/prefer_raw_string.rs

perfectionist::single_letter_closure_param↑ top

enabledclosure parameter has a single-letter name

What it does

Flags closure parameters whose identifier is one ASCII letter, unless the closure is a trivial single-expression callback. Two shapes qualify as trivial:

• the closure is the immediate argument of a call whose callee name is in the trivial-callback allowlist (sort_by, sort_by_key, min_by, max_by, binary_search_by, cmp_by, partial_cmp_by, fold, try_fold, …). The allowlist also covers the matching adaptors from itertools (sorted_by, k_smallest_by, minmax_by_key, …) and into-sorted (into_sorted_by, into_sorted_by_key, …);
• the body is a trivial wrapper around the parameter — a field access (|x| x.field), a method call (|x| x.foo()), a one-argument call where the parameter is the sole argument (|x| f(x)), a reference (|x| &x), or a macro call (|x| vec![x], |x| dbg!(x), |x| format!("{x}")). Surrounding * / & operators around the parameter inside any of the non-macro shapes are peeled before the match, so |s| (*s).foo() qualifies.

Why restrict this?

This is a stylistic preference, not a correctness issue. A multi-line closure body whose parameter is a single letter forces the reader to scroll back to the closure header for context on every reference. The trivial-callback exception covers sort_by(|a, b| ...) and .map(|x| x.field) shapes that are short enough that the parameter's role is unambiguous from the call site.

Example

.map(|t| {
    let columns = build_columns(t);
    format_row(&columns)
})

Use instead:

.map(|tree_row| {
    let columns = build_columns(tree_row);
    format_row(&columns)
})

Source: src/rules/single_letter_closure_param.rs

perfectionist::single_letter_function_param↑ top

enabledfunction parameter has a single-letter name

What it does

Flags function and method parameters whose identifier is one ASCII letter, except for a curated set of conventional names (n for an unsigned count, f for a fmt::Formatter, i / j / k for indices).

Why restrict this?

This is a stylistic preference, not a correctness issue. Parameter names are the first piece of documentation a caller reads (in rustdoc, in IDE hover tips, in error messages). A descriptive parameter name carries that documentation; a single letter does not.

Example

fn write_row(w: &mut Writer, t: &TreeRow) -> io::Result<()> { ... }

Use instead:

fn write_row(writer: &mut Writer, tree_row: &TreeRow) -> io::Result<()> { ... }

Source: src/rules/single_letter_function_param.rs

perfectionist::single_letter_generic↑ top

enabledgeneric type parameter has a single-letter name

What it does

Flags generic type parameters whose identifier is one ASCII letter (T, U, K, V, …), except inside trait impl blocks whose body fits within a small line threshold.

Why restrict this?

This is a stylistic preference, not a correctness issue. Single-letter generic names propagate through the type signatures and bounds; in a long impl block they force every reader to scroll back to the impl header to recover the role of each parameter. Descriptive names (Element, Key, Reader) keep complex signatures self-documenting. The short-trait-impl exception covers the canonical impl<T> From<T> for Wrapper<T> shape where the body is small enough that a reader cannot lose track of T.

Example

pub fn collect_keys<K, V>(map: BTreeMap<K, V>) -> Vec<K> {
    /* fifty lines */
}

Use instead:

pub fn collect_keys<Key, Value>(map: BTreeMap<Key, Value>) -> Vec<Key> {
    /* fifty lines */
}

Source: src/rules/single_letter_generic.rs

perfectionist::single_letter_let_binding↑ top

enabledlet binding has a single-letter name

What it does

Flags let x = ...; bindings whose identifier is one ASCII letter, outside #[cfg(test)] code.

Why restrict this?

This is a stylistic preference, not a correctness issue. A descriptive let binding documents what the right-hand side computed; a single-letter name does not. The rule allows let n = ... and other names in a configurable allowlist for the well-worn cases (unsigned counts), and switches off entirely under #[cfg(test)] where fixtures such as let a = ...; let b = ...; for interchangeable specimens are a recognised idiom.

Example

let m = entry.metadata()?;

Use instead:

let metadata = entry.metadata()?;

Source: src/rules/single_letter_let_binding.rs

perfectionist::unicode_ellipsis_in_comments↑ top

enabledU+2026 HORIZONTAL ELLIPSIS in non-doc comments; prefer ...

What it does

Forbids U+2026 HORIZONTAL ELLIPSIS (…) in regular // and /* */ comments. Doc comments (///, //!) are covered by a sibling lint.

Why restrict this?

This is a stylistic preference, not a correctness issue. ASCII ... survives every encoding round-trip, every terminal, every grep invocation, and every git diff viewer without rendering as ? or a tofu box. The Unicode form usually arrives by accident from autocorrect.

Example

// TODO: handle the empty-tree case…

Use instead:

// TODO: handle the empty-tree case...

Source: src/rules/unicode_ellipsis_in_comments.rs

perfectionist::unicode_ellipsis_in_panic_messages↑ top

enabledU+2026 HORIZONTAL ELLIPSIS in panic / assertion / expect messages; prefer ...

What it does

Forbids U+2026 HORIZONTAL ELLIPSIS (…) in the message of a panic-family or assertion-style macro (panic!, unimplemented!, todo!, unreachable!, assert!, assert_eq!, assert_ne!, debug_assert*!) and in the expect / expect_err argument on Option and Result. Prefer the three-ASCII-dot form ....

Why restrict this?

This is a stylistic preference, not a correctness issue. Panic and assertion messages surface in stderr, CI logs, crash reporters, and on terminals whose locale or encoding may not be UTF-8. ASCII ... renders identically everywhere.

Example

panic!("could not parse manifest…");
let manifest = load().expect("config missing…");

Use instead:

panic!("could not parse manifest...");
let manifest = load().expect("config missing...");

Custom macros

The extra_macros configuration accepts any macro name, but the lint's per-macro knowledge of which argument is the message only covers the built-in panic / assertion macros. A custom macro added through this knob is treated as if its first argument were the message; an assert_eq!-shaped wrapper would therefore also scan its value-position literals. Adding per-macro skip counts requires extending the configuration schema and is out of scope for the initial rule.

Source: src/rules/unicode_ellipsis_in_panic_messages.rs

perfectionist::unknown_perfectionist_lints↑ top

enabledlint-control attribute references a perfectionist::* lint that this plugin does not register

What it does

Flags lint-control attributes (allow, warn, deny, forbid, expect, including under cfg_attr) whose lint name starts with perfectionist:: but does not name a lint this plugin actually registers.

Why is this bad?

Typos and stale references in #[allow(perfectionist::...)] silently neutralise the suppression they were written for. rustc's own unknown_lints covers tool-prefixed names inconsistently; this rule fills the gap and offers a "did you mean" hint against the registered set.

Example

#[allow(perfectionist::unicode_ellipsis_in_comment)] // typo
fn legacy() {}

Use instead:

#[allow(perfectionist::unicode_ellipsis_in_comments)]
fn legacy() {}

Source: src/rules/unknown_perfectionist_lints.rs