In macros invocation, a comma is inserted after struct/enum declaration

[scrabsha]

TLDR: a , is inserted between struct/enum declaration and other fragment specifiers in macros, which cause them to break after formatting.

This happens for both tupled and named structs and enums, but does not happen for unions. This is clearly not linked to the macro definition itself.

Input

mac!(struct Foo {} bar);
mac!(struct Foo; bar);
mac!(enum Foo {} bar);

Output

mac!(struct Foo {}, bar);
mac!(struct Foo;, bar);
mac!(enum Foo {}, bar);

Notice the , inserted between the struct/enum declaration, which can break the macro.

Expected output

mac!(struct Foo {} bar);
mac!(struct Foo; bar);
mac!(enum Foo {} bar);

I have created a playground link, so that it is easier to see what's wrong.

Meta

• rustfmt version: rustfmt 1.4.15-stable (530eadf 2020-06-02) (tested, also reproducible on the playground)
• From where did you install rustfmt?: Installed via NixOS package manager, but also happens on the playground.

Feel free to ping me if other information is needed.

Edits

• 2020/08/27: specify that this is independent from the macro definition itself, mention enums and unions.

[ayazhafiz]

This is possible to fix today, but only by looking at the original "shape" of the macro call. More sophisticated solutions would require us to look at how the macro is defined, which we don't have access to at the AST level. I am saying this because it's possible to fix, but would be kind-of hacky and may bring more problems.

[scrabsha]

More sophisticated solutions would require us to look at how the macro is defined, which we don't have access to at the AST level. I am saying this because it's possible to fix, but would be kind-of hacky and may bring more problems.

Completely agree: this is not the best way to fix the issue. Additionally, this wouldn't solve the issue when the macro itself is not defined.

IMO no tokens should be added or removed in macros (unless the macro is defined for instance in the standard library), but I may be wrong.

[ytmimi]

Confirming this is still reproducible with rustfmt 1.5.1-nightly (a451a39d 2022-07-25)