Trailing spaces removed when formatting `&str` over `max_width`

When there is a &str with trailing spaces that exceeds the max_width rustfmt formats in a way that removes trailing spaces, resulting in different output.

Settings

format_strings = true
max_width = 30
tab_spaces = 1

Description

Note: Line numbers have been added and spaces are replaced with · for clarity.

When trying to format a line like:

1| ··"457890123456789012345678··"

, rustfmt will suggest a new line of:

1| ··"457890123456789012345678·\
2| ····"

If you attempt to add back the space that was removed:

1| ··"457890123456789012345678··\
2| ····"

rustfmt again, suggests removing the space:

1| ··"457890123456789012345678·\
2| ····"

To Reproduce

Also see a minimal, reproducible example.

src/main.rs

fn main() {
 let a = vec![
  // single-line
  "457890123456789012345678  ",
  // multi-line
  "457890123456789012345678  \
    ",
 ];
 assert_eq!(a[0].len(), 26);
 assert_eq!(a[1].len(), 26);
}

• Run cargo run to see that code runs successfully
• Run cargo +nightly fmt --all -- --emit files
• Run cargo run to see that the code fails

The &strs that are created should both have a length of 26.

Expected behavior

Overall, I wouldn't expect rustfmt to change the values of the &strs, though I'm not sure how exactly this should be handled.

Meta

Rust version: 1.50.0-nightly

rustfmt versions:

• 1.4.29-nightly (70ce182 2020-12-04) from crates.io
• 1.4.30-nightly (acd9486 2020-12-20) from GitHub releases
• master (367a874d04abfb2269ff1ea1974f06640546b7c5)

Start with the reproducible example in src/main.rs and run cargo +nightly fmt --all -- --emit files, then cargo run to confirm the changed string value. Investigate rustfmt's handling of format_strings and max_width for the shown trailing-space case. Done means formatting preserves both &str values at length 26 and the example continues to run successfully.