fix: don’t format mixed macro args (items + non-items) (#6629)

[giammirove]

Fixes #6629

Problem

The following code:

macro_rules! reproduce { (type Fail = $ty:ty; arr = $($arr:expr),*) => { ( vec![$($arr),+] ) }; } fn main() { reproduce!(type Fail = char; arr = 1); }

is formatted as:

macro_rules! reproduce { (type Fail = $ty:ty; arr = $($arr:expr),*) => { ( vec![$($arr),+] ) }; } fn main() { reproduce!(type Fail = char;, arr = 1); } 

Notice the , right after ; in the macro invocation.
Making the formatted code's syntax wrong.

Solution

When formatting a list of commented items into a list (write_list in src/lists.rs), do not add the comma if the item's entry ends with ;.

Changes

• Modified write_list in src/lists.rs to avoid adding , if the argument ends with ;.
• Added regression test case issue-6629.rs to prevent future regressions

[giammirove]

I found an edge case for which my fix would break the code.

The following code:

macro_rules! reproduce { (type Fail = $ty:ty; arr = $($arr:expr),+) => { ( vec![$($arr),+] ) }; ( $expr:expr, $($arr:item),+) => { 1 }; } reproduce!(type Fail = char; arr = 1); 

is rewritten as:

reproduce!(type Fail = char;, arr = 1); 

which is not valid code.

The problem is related to mixed argument types (items and non items).
The code responsible for parsing the macro arguments is parse_macro_args in src/parse/macros/mod.rs. parse_macro_args interpret type Fail = char; as an item, while arr = 1 as an array of expr.
While parse_macro_args parses the arguments, it does not detect any ;, since ; is part of the item (items are self-terminating).
Therefore, the arguments are later treated as vec![1,2,3,4], and write_list will append , after every argument, breaking the code.
My previous fix was to avoid appending , after ;. Such a fix would break other valid code, see:

reproduce!(23, type Fail = char;, type Fail = char;); 

is rewritten as:

reproduce!(23, type Fail = char; type Fail = char;); 

which is not valid code, since the macro accepts arguments like ($($arr:item),+).

The problem is therefore related to the presence of both item and non item arguments.
Currently, no implementation accounts for this case scenario in rewrite_macro_inner in src/macros.rs.
The current solution uses a conservative approach, where mixed macro arguments are not formatted.