[Feature Request] Attempt to format brace macros as Block

[nhynes]

For instance,

wrapper! {
use std::  collections::HashMap;
pub fn the (a: sdf )
{
    ( )
}
}

Removing this conditional in rewrite_macro_inner gets most of the way there, but leaves things like Use statements unformatted:

wrapper! {
    use std::  collections::HashMap;
    pub fn the(a: sdf) {
        ()
    }
}

[scampi]

In the issue #3434, formatting of such macros is not wanted. Maybe there could be a configuration option to toggle formatting of brace macros.

Edit: Actually, it was proposed to extend the skip attribute to prevent formatting a macro #3434 (comment)

[arilotter]

Maybe there could be a configuration option to toggle formatting of brace macros.

A configuration option or an attribute to explicitly enable formatting the inside of a macro with a specific name would be incredibly useful :)

[nhynes]

#[rustfmt::noskip]

perhaps?

[Hentioe]

Building DSL code requires macro block formatting ...

[whatisaphone]

In the issue #3434, formatting of such macros is not wanted.

I think when rustfmt sees a macro block, it should check the contents to see if it's valid Rust syntax. If yes, format it as Rust code. If not, leave it alone (under the assumption that it's a different non-Rust language).

The HTML in #3434 is not valid Rust syntax, so it would not be changed. But most uses of macro blocks (the OP, thread_local! {}, etc) are valid Rust syntax, so they would be formatted.

[calebcartwright]

Going to close this in an effort to consolidate duplicative threads.

I think when rustfmt sees a macro block, it should check the contents to see if it's valid Rust syntax. If yes, format it as Rust code. If not, leave it alone (under the assumption that it's a different non-Rust language).

The fundamental progress with this is that there's overlap between arg tokens that can be parsed as valid Rust syntax but actually are not, and applying the valid-Rust formatting rules to them can, and has, actually been a problem when using other call delims, with the only viable resolution being to either switch to the brace delim or adding the skip attribute on the call.

It's simply not possible for rustfmt to ever be able to safely make that assumption, which is why a categorical approach is not viable. Something like the more explicit opt-in approaches that have been discussed elsewhere is probably the best middle ground