Skip to content

Trailing spaces removed when formatting &str over max_width #4608

Open
@MitMaro

Description

@MitMaro

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 (367a874)

Metadata

Metadata

Assignees

No one assigned

    Labels

    a-whitespacebugPanic, non-idempotency, invalid code, etc.only-with-optionrequires a non-default option value to reproduce

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions