If a line is too long after formatting, rustfmt gives up on formatting this line

[ArmoredPony]

Here is a &str constant with a very long string literal assigned to it:

const REQUIRED_SYMBOLS: &str = "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

The total length of this line is 129 characters. This line is not formatted at all. For example, I can do this ugliness

const   REQUIRED_SYMBOLS   :   &     str   =  "qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

and these spaces will not be removed upon formatting. However, if we remove just two characters from the string, the line above gets formatted just fine (notice how it splits into two lines):

const REQUIRED_SYMBOLS: &str =
    "qwertyuiosdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM`1234567890-=[]\\;',./~!@#$%^&*()_+{}:\"<>?";

The second line's length with indentation is exactly 100 characters which is the default max_width parameter value. It seems like rustfmt gives up on formatting such statements if it exceeds the max_width even after splitting it.

It doesn't have to be a constant, it may be a variable and it may have a longer name. Only string literal's length matters.

This test used default rustfmt.toml config. In my config, max_width is 80. With that config enabled I have to delete more symbols for rustfmt to format this line.

[calebcartwright]

If you have the ability to change to version=Two in your config you'll pull in the update which will apply formatting, but that's gated intentionally which is why you're not seeing it.

This will be applied by default when running cargo fmt with the 2024 edition