Rustfmt: Multiline closures with a single expression that's a macro call with {} are always wrapped in a block, but [] macro calls aren't.

Created on 14 Nov 2019  路  5Comments  路  Source: rust-lang/rustfmt

Using this sample macro which turns a list of token trees into a block (simplified from a real macro that does more transformations)

macro_rules! blockify {
  ($($block:tt)*) => {
    { $($block)* }
  };
}

rustfmt will transform the following expression

drop(|| blockify! {
    // do something
});

into

drop(|| {
    blockify! {
        // do something
    }
});

However, it doesn't do the same with macros that use [] until they're significantly longer.

    drop(|| vec![1 + 1, 2 + 2, 3 + 3]);
    drop(|| {
        vec![
            1 + 1 + 1 + 1 + 1 + 1 + 1,
            2 + 2 + 2 + 2 + 2 + 2 + 2 + 2,
            3 + 3 + 3 + 3 + 3,
        ]
    });
}

I would expect the same behaviour with [] and {} macro calls, or at least an option so I can make {} macros use the same rules as [] macros here.

All 5 comments

At first glance this seems to have similarities with #3605 where a block is being added to the body of the closure

I believe this is not a duplicate, though, it might be documenting the same behavior. This happens regardless of whether the closure takes parameters.

IIRC rustfmt adds a block if the body of the closure is multi-lined.

IIRC rustfmt adds a block if the body of the closure is multi-lined.

Ah, I see how this rule applies to my examples.

Would rustfmt take a PR that adds a way to disable this?

I'm closing this issue because the behavior is "rustfmt adds a block if the body of the closure is multi-lined", which is consistent - there's no issue here.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

fulara picture fulara  路  4Comments

scampi picture scampi  路  4Comments

tkilbourn picture tkilbourn  路  5Comments

MoSal picture MoSal  路  5Comments

ratmice picture ratmice  路  3Comments