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.
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.