error[internal]: left behind trailing whitespace

[simonsan]

I never had that before, but rustfmt fails for me with an error error[internal]: left behind trailing whitespace for this (I tried to break it down to the minimal example code below):

error[internal]: left behind trailing whitespace
  --> \\?\C:\Users\dailyuse\Desktop\repro-rustfmt\repro\src\lib.rs:16:16:1
   |
16 |
   | ^^^^^^^^
   |

warning: rustfmt has failed to format. See previous 1 errors.

A repository with the code can be found here: https://github.com/simonsan/rustfmt_repro

use std::result::Result;

type TestError<T> = Result<T, Box<dyn std::error::Error>>;

pub fn test() -> TestError<Vec<usize>> {
    Ok(vec![1, 2, 3])
}

fn end_all_unfinished_activities(activities: Vec<u64>) -> TestError<Vec<usize>> {
    activities
            .iter()
            .for_each(|_| {
                match "Ok(true)" {
                    "bla" => {

        

                    },
                    "bli" => {
                        log::warn!(
                            "Activity {} activity ends before it began. That's impossible. Skipping activity.", "test".to_string()
                        )
                    },
                    _ => {}
                };
            });

    Ok(vec![1, 2, 3])
}

In the match arm "bla", between the brackets are some whitespaces. If you remove the log::warn!() it works again, so it's definitely related. I wonder though, if this could be considered a bug in rustfmt?

Related: #6054 (?)

[ytmimi]

The issue here is the "bli" match arm. You're running into #3863, and as a result rustfmt doesn't remove the whitespace that exists in your source code in the "bla" match arm.

There are a few ways you can work around this:

1. bump the max width so that the long log::warn! call can be formatted within the max with.
2. set format_strings=true so that rustfmt can try to break the long string literal to keep things within the max_width
3. refactor your code to keep things within the max_width

[simonsan]

Ah, interesting. I have not experienced that behaviour before, so I was surprised. Thanks for explaining the workarounds, much appreciated!