Rustfmt breaks attributed blocks only containing comments

[vallentin]

I was refactoring and commented out a chunk of code inside an attributed block. Wherein rustfmt proceeded to format the code, by repeating the attribute(s) (the first without the #) and the starting brace within the block.

I've tried a few variations, and the issue seems to occur, if a block has at least one attribute, while the block itself only contains comments. (Adding just a single line of code anywhere in the block, before or after the comment(s) stops the issue.)

The issue occurs both on stable and nightly.

Line Comments

Before rustfmt:

fn main() {
    #[cfg(feature = "foo")]
    {
        // let foo = 0;
    }
}

After rustfmt (both stable and nightly):

fn main() {
    #[cfg(feature = "foo")]
    {
        [cfg(feature = "foo")]
    { // let foo = 0;
    }
}

Block Comments

Before rustfmt:

fn main() {
    #[cfg(feature = "foo")]
    {
        /*
        let foo = 0
        */
    }
}

After rustfmt (both stable and nightly):

fn main() {
    #[cfg(feature = "foo")]
    {
        [cfg(feature = "foo")]
    { /*
         let foo = 0
         */
    }
}

Exception

I found one exception. If the block only contains a single block comment, and it is specifically written in a single line. Then rustfmt still formats it, but not in a way that breaks the code.

Before rustfmt:

fn main() {
    #[cfg(feature = "foo")]
    {
        /* let foo = 0; */
    }
}

After rustfmt (both stable and nightly):

fn main() {
    #[cfg(feature = "foo")]
    { /* let foo = 0; */ }
}

Multiple Attributes

Before rustfmt:

fn main() {
    #[foo]
    #[bar]
    #[baz]
    {
        // let foo = 0;
    }
}

After rustfmt (both stable and nightly):

fn main() {
    #[foo]
    #[bar]
    #[baz]
    {
        [foo]
    #[bar]
    #[baz]
    { // let foo = 0;
    }
}

---

rustfmt 1.4.20-stable (48f6c32 2020-08-09)
rustfmt 1.4.24-nightly (eb894d5 2020-11-05)

[vallentin]

rustfmt 1.4.18-stable (8157a3f 2020-07-15)

Went back a few versions and the issue doesn't appear in 1.4.18.

[calebcartwright]

Thank you for the report and detail, though going to close as duplicate of #4382

Unfortunately that fix never got backported, but I'll cut a v1.4.26 release here shortly with the fix