Gives up on chains if any line is too long.

[ehuss]

If there is a method call chain, and just one call exceeds max_width, it seems like rustfmt gives up and doesn't format anything.

Example:

fn f() {
    foo("This text is under the max_width limit, and shouldn't cause any problems on its own.").long("But this line is extra long, and doesn't fit within 100 max_width. 1234567890123456789").baz().collect().unwrap();
}

No format changes will be applied to this. I'm also a bit surprised that error_on_line_overflow does not complain.

I would expect it to wrap each call chain element, even if one of them is too long, such as:

fn f() {
    foo("This text is under the max_width limit, and shouldn't cause any problems on its own.")
        .long("But this line is extra long, and doesn't fit within 100 max_width. 1234567890123456789")
        .baz()
        .collect()
        .unwrap();
}

All default settings.
rustfmt 1.4.8-nightly (afb1ee1 2019-09-08)

[calebcartwright]

Yeah, AFAICT that's because rustfmt is expecting to be able to rewrite each of the individual ChainItems to be able to format the Chain. When it attempts to rewrite that long string literal in the Chain it fails due to the length which results in the entire original chain being left as-is.

rustfmt/src/chains.rs

Lines 419 to 444 in a15e97f

	fn rewrite(&self, context: &RewriteContext<'_>, shape: Shape) -> Option<String> {
	debug!("rewrite chain {:?} {:?}", self, shape);
	let mut formatter = match context.config.indent_style() {
	IndentStyle::Block => {
	Box::new(ChainFormatterBlock::new(self)) as Box<dyn ChainFormatter>
	}
	IndentStyle::Visual => {
	Box::new(ChainFormatterVisual::new(self)) as Box<dyn ChainFormatter>
	}
	};
	formatter.format_root(&self.parent, context, shape)?;
	if let Some(result) = formatter.pure_root() {
	return wrap_str(result, context.config.max_width(), shape);
	}
	// Decide how to layout the rest of the chain.
	let child_shape = formatter.child_shape(context, shape)?;
	formatter.format_children(context, child_shape)?;
	formatter.format_last_child(context, shape, child_shape)?;
	let result = formatter.join_rewrites(context, child_shape)?;
	wrap_str(result, context.config.max_width(), shape)
	}

I think I see a way we could support still wrapping chain elements like your expected output, though it would mean rustfmt emitting a line that exceeds the max_width (although the original line does too, and the wrapped version is more human friendly IMO even with the one longer line).

@topecongiro @scampi - any concerns with that? if not, then I'll take a look at implementing something for consideration.

[scampi]

@calebcartwright sounds good to me!

[agate-pris]

I think this issue is duplicate of #2970 .

[NilsIrl]

Using format_strings pretty much fixed it for me as strings get broken up and rustfmt can keep the line length below max_width.

[joshtriplett]

I just ran into this as well. My code:

fn main() {
    clap::App::new("foo")
        .subcommand(
            SubCommand::with_name("bar")
                .about("some text here")
                .setting(AppSettings::ArgRequiredElseHelp)
                .arg(
                    Arg::from_usage("-l, --latest 'some very long help text goes here [default: default version]'")
                                               .conflicts_with(  "template_version"  )
                )
        )
        .get_matches();
}

rustfmt seems to completely give up after the line with the long help text, and doesn't even try to reindent the .conflicts_with, or fix the spacing in its argument, or add a trailing comma in either of the two places that should have trailing commas.

I'd expect rustfmt to do best-effort on the long line, and then continue afterward.

[calebcartwright]

Doing something about this is still on my to-do list, though I do think it's worth expanding a bit on what folks have in mind when we say "best effort".

It seems this is most often encountered with a single long string, but will also note there are plenty of other scenarios that can run into this where IMO the expected behavior starts to get a little tricky. Consider for example a chain whose parent starts in a heavily indented position, and the chain element that exceeds the max width value is a closure param that itself has a sizeable body with additional nested indentation.

Would users still want rustfmt to format that closure anyway even though it blows way past the max width value? Are we changing the meaning/honoring of max width with a caveat of "except within chains"? Should rustfmt do this by default or should users have to explicitly opt-in to allowing rustfmt to exceed the max width when there are chains involved?

[joshtriplett]

@calebcartwright In general, I'd expect rustfmt to indent everything to the correct level, and try to wrap appropriately at line-width, but whether it's successful or not, it should continue on to wrap the rest, yes.

It's not "except within chains", it's "when possible, without violating more important constraints like properly indenting". If you have an indent-width of 4, and (say) 15 levels of indentation and a 50-character function name, you cannot format that without exceeding 100 characters, and that shouldn't stop you from continuing on to format more of the line. And if you need to wrap the function parameters, those should still get indented 16 levels, even if one of them is a long string.

[calebcartwright]

more important constraints like properly indenting

What defines the relative importance of one constraint vs. another though? Is there a consensus on which constraints can be violated? Does the style guide have a prescription? The only thing I'm familiar with (and I know you're far more familiar with the style guide than I @joshtriplett 😄) is https://github.com/rust-dev-tools/fmt-rfcs/blob/7416e12356a55aae959e9629b58eb7c7c3c86f6f/guide/guide.md#indentation-and-line-width

It's not that we can't technically make this change, but in these types of scenarios where rustfmt can't satisfy all the constraints it bails and defers to the programmer to format, or refactor, as needed. This is usually quite manageable, and often accompanied with advice like refactor your code to avoid long/complex expressions, usually by extracting a local variable or using a shorter name

If you have an indent-width of 4, and (say) 15 levels of indentation and a 50-character function name, you cannot format that without exceeding 100 characters

Precisely and agreed, I was just trying to keep the example in the context of chains given the issue.

There's also portions of the user base that do want to strictly enforce the width limits in their code and would leverage options like error_on_line_overflow to ensure that any violations of the width constraints were indeed raised, and any changes to the behavior would have to continue to honor that (an implementation detail that I'm just noting for future reference).

I also think that if max width were to be changed to more of a soft constraint then we'd need to explicitly convey that rustfmt will format your code within the limit, unless it really can't, in which case it will format out indentations indefinitely as needed.

[nazar-pc]

I very much agree with Josh here, but I think even bigger issue is that there are no visible errors/warnings that formatting is not possible and why.
It just silently gives up, leaving user guessing why this particular part of the code is not formatted correctly.

[calebcartwright]

@nazar-pc try running with --config error_on_line_overflow=true which exists for precisely this purpose (make sure you're on nightly), it's just disabled by default. If you'd like to make a case for that being enabled by default then #3391 would be the place to do so

example output with that enabled:

error: line formatted, but exceeded maximum width (maximum: 100 (see `max_width` option), found: 115)
 --> <stdin>:8:8:101
  |
8 |                     Arg::from_usage("-l, --latest 'some very long help text goes here [default: default version]'")
  |                                                                                                     ^^^^^^^^^^^^^^^
  |

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

[MonliH]

Another bug caused by this issue, that makes my editor's formatter, which uses rustfmt, anrgy (I'd imagine many more like this, it's happened to me in match statements as well):

Input:

fn main() {
    (
        foo, 
        "this is a long line that breaks rustfmt, let's make it even longer foo bar foo bar foo bar"
    )
}

Note the trailing space after foo,

Output:

error[internal]: left behind trailing whitespace
 --> /playground/src/main.rs:3:3:12
  |
3 |         foo, 
  |             ^
  |

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

Playground Link

[calebcartwright]

@MonliH - that's not really a separate bug or strictly related to this issue. Your original snippet has a trailing space which is the root cause (rustfmt isn't inserting a random trailing space), rustfmt is just leaving your original snippet as is and highlighting the fact that it did not remove the trailing spaces.

[Lorak-mmk]

Do I understand correctly that if I have too long string literal then rustfmt will just ignore the whole function without any warning / error, and there is nothing that stable toolchain users can do about it because format_strings and https://rust-lang.github.io/rustfmt/?version=master&search=overflow#error_on_line_overflow are all unstable? And this situation is going on for 5 years now? Great...

[tylerlaprade]

Here's my suggestion:

Rustfmt should treat this case the same as Prettier, Biome, Black, Ruff, and I assume many other auto-formatters which I'm not familiar with. Namely, treat the max width as a target but not a strict maximum. They try their best to get lines to fit under that length, but if they can't, they can't and that's fine. They still get the line as short as possible.

[kolbma]

Here's my suggestion:

Rustfmt should treat this case the same as Prettier, Biome, Black, Ruff, and I assume many other auto-formatters which I'm not familiar with. Namely, treat the max width as a target but not a strict maximum. They try their best to get lines to fit under that length, but if they can't, they can't and that's fine.

It could write a warning to stderr, with a config option disable_warning_on_ignored_line.
Both existing options, next to only existing in nightly, have the problem, that you still have the problem with code styling.
If you set a longer max line length it restyles all your code.
If you set the error on overflow, it errors and you have to fiddle around to get the line shorter.
Which is also not so easy viewable, because IDE inserts virtually the types and makes lines virtually longer they are.

And overall I don't understand why it ignores the other lines of code block following the long line.
This looks like a bug and should have been fixed separately to introducing options as a workaround.

[theoparis]

Do I understand correctly that if I have too long string literal then rustfmt will just ignore the whole function without any warning / error, and there is nothing that stable toolchain users can do about it because format_strings and https://rust-lang.github.io/rustfmt/?version=master&search=overflow#error_on_line_overflow are all unstable? And this situation is going on for 5 years now? Great...

I tried using the following rustfmt.toml and nightly rust and it still doesn't seem to be formatting any of my code... I guess this still needs to be fixed in nightly rust as well.

format_strings = true
unstable_features = true

[ilyvion]

Before I make this a new issue, can someone check whether or not this issue I'm running into has the same cause as this issue? This isn't the exact code I'm having trouble with, but it behaves identically, so it's a good MRE: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f52f18c42f46824eb308281c23ed978e

If you run rustfmt on it, you'll see the code doesn't get properly formatted. In particular, ,dynamic_assets remains without a space after the comma, but also any other bad formatting in the same block remains broken if you mess it up further and try to run formatting on that.

To make rustfmt work again, simply shorten the length of the parameters in the closure. You can make it |asset: Vec<AssetServer>, dynamic: Vec<DynamicAssets>|, e.g. and it formats, or |asset_server: Vec<Asset>, dynamic_assets: Vec<Dynamic>| but it feels wrong to me that formatting entirely stops working in a whole block of code just because some names/lines end up too long.

[Sieabah]

This was affecting me for a few days, was getting around it by just manually formatting but I was getting desperate. I installed nightly and added the extra fields which ended upbreaking a string and reflowing another expression. I've found though that if you have highly nested match/if statements the whitespace counts towards the max width. I imagine most use spaces so that's 2-4 characters wasted on each indent instead of 1 per tab. Indents also can't be "reflowed" so it creates a similar problem to strings which are >97 (accounting for the "/' and the trailing comma if used in a function argument.

I think this is an absolutely insane limitation that it doesn't warn or error at all outside of nightly. I had been trying to find any reason this wasn't compiling and it turns out this issue was exactly what I was running into the whole time.

@ilyvion Your snippet clued me into whitespace being an issue as well. For yours I'd expect the formatter to break the closure into multiple lines. You're right that this silently failing is a huge problem.

    {
        {
            {
                {
                    {
                        {
                            once::run(move |asset_server: Vec<AssetServer>,dynamic_assets: Vec<DynamicAssets>| {
                                load_dynamic_asset(
                                    &dynamic_assets,
                                    &asset_server,
                                    "dialogs",
                                    &dialog,
                                )
                                .expect(&dialog)
                            })
                        }
                    }
                }
            }
        }
    }

I'm unsure why this has been allowed to persist for 4-5 years. Especially given that because it's silent and it only ever doesn't run when it can't compile. So when it compiles and doesn't format... It's a game of whack a mole to figure out which fmt rule is breaking, installing nightly and developing within that isn't feasible since it's nightly.