Skip to content

perfectionist::import_grouping single_group cannot keep #[cfg]-gated imports in their own group #436

@KSXGitHub

Description

@KSXGitHub

Context

While upgrading perfectionist to 0.0.0-rc.18 (which introduces the
import_grouping rule), this project adopted the single_group style:

["perfectionist::import_grouping"]
style = "single_group"

The problem

single_group requires that no blank line sit between any two statements
of an import run. However, this project has a long-standing convention
(documented in CONTRIBUTING.md) of keeping platform/feature-gated
imports in their own trailing block, separated by a blank line:

use super::size::Bytes;
use std::fs::Metadata;

#[cfg(unix)]
use super::size::Blocks;
#[cfg(unix)]
use std::os::unix::prelude::MetadataExt;

This separation is desirable: the unconditional imports and the
#[cfg]-gated ones are conceptually distinct, and the blank line makes
the boundary obvious. The grouped style already models this through its
cfg_block_handling = "trailing" knob, but single_group has no
equivalent, so it flags every such file.

Suggestion

single_group should treat a run of #[cfg(...)]-gated imports as an
allowed trailing group, the same way grouped does with
cfg_block_handling = "trailing". A dedicated knob (for example
cfg_block_handling on single_group, defaulting to trailing) would
let a project opt in or out.

Workaround in this repository

Until this is addressed upstream, the affected files carry a
module-level suppression:

#![expect(
    perfectionist::import_grouping,
    reason = "single_group cannot keep #[cfg]-gated imports in their own trailing group; see issue #436"
)]

This issue tracks removing those suppressions once single_group can
express the trailing #[cfg] group.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions