Rustfmt incorrectly adds whitespace inside multiline string literals within macro calls that have curly braces

[Aiden2207]

Code:

macro_rules! test {
    ($l:literal) => {};
}

fn main() {
    test!{
        "
"};
}

expected output:

macro_rules! test {
    ($l:literal) => {};
}

fn main() {
    test!{
        "
"
    };
}

actual output:

macro_rules! test {
    ($l:literal) => {};
}

fn main() {
    test! {
            "
    "};
}

Rustfmt added an extra indentation to the literal, including inside the string itself. This only occurs when the macro invocation is delimited by curly brackets, it works fine when square or parentheses are used.

[ytmimi]

Thanks for the report! Confirming that I can reproduce this on rustfmt 1.4.38-nightly (63acf900 2022-03-27)

[ytmimi]

I'm pretty sure the error can be tracked down to trim_left_preserve_layout in this match arm:

rustfmt/src/macros.rs

Lines 326 to 334 in 7d6ca7c

	DelimToken::Brace => {
	// For macro invocations with braces, always put a space between
	// the `macro_name!` and `{ /* macro_body */ }` but skip modifying
	// anything in between the braces (for now).
	let snippet = context.snippet(mac.span()).trim_start_matches(|c| c != '{');
	match trim_left_preserve_layout(snippet, shape.indent, context.config) {
	Some(macro_body) => Some(format!("{} {}", macro_name, macro_body)),
	None => Some(format!("{} {}", macro_name, snippet)),
	}

[zeenix]

Rustfmt added an extra indentation to the literal, including inside the string itself. This only occurs when the macro invocation is delimited by curly brackets, it works fine when square or parentheses are used.

Unfortunately this workaround doesn't work for me with rust-analyzer, as it (or cargo fmt) automatically replace [] and () with {} for me. :(

[ytmimi]

@zeenix can you please post a code snippet of the issue you're seeing so we can more easily investigate this when we have time, thanks!

[zeenix]

@zeenix can you please post a code snippet of the issue you're seeing so we can more easily investigate this when we have time, thanks!

It's in the commit that mentioned this issue: zeenix/endi@868afee . If you split the concat! arguments over multiple lines, you'll reproduce the issue.

[ytmimi]

@zeenix It's possible that your issue is related to this one, but it sounds like you're running into #5974

[zeenix]

@zeenix It's possible that your issue is related to this one, but it sounds like you're running into #5974

Ah, you're likely correct. Thanks.