Prevent ICE when formatting item-only vec!{}

[tdanniels]

Prevent ICE when formatting item-only vec!{}

Fixes #5735

Attempting to format invocations of macros which are considered "forced bracket macros" (currently only vec!), but are invoked with braces instead of brackets, and contain only items in their token trees, currently triggers an ICE in rustfmt. This is because the function that handles formatting macro invocations containing only items, rewrite_macro_with_items, assumes that the forced delimiter style of the macro being formatted is the same as the delimiter style in the macro's source text when attempting to locate the span after the macro's opening delimiter. This leads to the construction of an invalid span, triggering the ICE.

The fix here is to pass the old delimiter style to rewrite_macro_with_items as well, so that it can successfully locate the span.

---

Hi rustfmt'ers! I'm back again with another ICE fix. Some notes for the reviewer:

• With how I've implemented this fix, the original reproducing case

fn find_errors(mut self) {
	let errors: Vec<> = vec!{
		#[debug_format = "A({})"]
		struct A {}
	};
}

will be formatted into

fn find_errors(mut self) {
    let errors: Vec = vec![
        #[debug_format = "A({})"]
        struct A {}
    ];
}

I understand that the team's stance is that braced macro invocations should generally be left unformatted. However, the current behaviour of rustfmt on braced vec! invocations is to format them. That is, before this PR, rustfmt will turn vec!{1, struct X {} } into vec![1, struct X {}];.
My PR doesn't change this behaviour. It just extends a similar behaviour to vec! invocations that contain only items. So with my PR, whereas formatting vec!{ struct X {} } would previously have triggered an ICE, it's now formatted into

vec![
    struct X {}
];

I'm not entirely sure that this is the 'right' direction to go in, but the alternative of leaving braced, item-only vec! invocations unformatted seemed about equally surprising to me from a user perspective. Any feedback here is appreciated, and I'm happy to tweak the implementation to whatever behaviour the team thinks is best.

• I've also included a small refactoring commit of some redundancy I noticed while working in macros.rs. I'm happy to split that off into a separate PR if that's what people prefer.

• Clippy isn't happy that I've added another parameter to rewrite_macro_with_items, pushing it over the threshold of 7 parameters. I didn't see a way to cleanly keep it below the threshold while still passing in the original delimiter style, but as usual any suggestions are appreciated.

[calebcartwright]

Thanks for another PR!

r? @fee1-dead

[fee1-dead]

LGTM

[tdanniels]

Rebased on to the latest master.

[ytmimi]

@tdanniels Thanks for the help on this one. I think the approach of passing the original style to locate the correct opener makes a lot of sense.

Happy to merge this after rebasing on the latest master.

[tdanniels]

Thanks for the reviews everyone! @ytmimi it should be all up to date now.

[ytmimi]

You're very welcome! Again, really appreciate the help!