You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cannot set granular width configuration settings to 100% if max_width = 100 #5404
The granular width configuration settings are documented to be percentages of max_width (e.g. chain_width). However when max_width is set to 100 setting their values to 100 causes a warning
`fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`
The error message is both surprising and incorrect since fn_call_width = 100 is not a value that exceeds max_width.
This does not happen if max_width is 99 or 101.
The exact config options that trigger this bug are:
Just as a heads up, when filing an issue please try to include a minimum code example that can be used to reproduce the issue along with any configuration options needed to produce the issue. It was a little tricky to track down since I tried running rustfmt on a few files and I couldn't reproduce the error until I ran rustfmt against src/utils.rs. Doing so the error is emitted 4 times.
Running rustfmt with debug logging enabled (RUSTFMT_LOG=rustfmt=DEBUG rustfmt --config-path=issue_5404.toml --emit stdout src/utils.rs) reveals that this error is always emitted after calling replace_names:
[2022-06-28T17:05:55Z DEBUG rustfmt_nightly::macros] replace_names `zsp.source_callsite()` {"$sp": "zsp"}
`fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`
[2022-06-28T17:05:55Z DEBUG rustfmt_nightly::macros] replace_names `!zself.config.file_lines().is_all()
&& !zself
.config
.file_lines()
.intersects(&zself.parse_sess.lookup_line_range(zspan))` {"$span": "zspan", "$self": "zself"}
`fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`
[2022-06-28T17:05:55Z DEBUG rustfmt_nightly::macros] replace_names `if out_of_file_lines_range!(zself, zspan) {
return None;
}` {"$self": "zself", "$span": "zspan"}
`fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`
[2022-06-28T17:05:55Z DEBUG rustfmt_nightly::macros] replace_names `if out_of_file_lines_range!(zself, zspan) {
zself.push_rewrite(zspan, None);
return;
}` {"$span": "zspan", "$self": "zself"}
`fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`
replace_names only gets called in MacroBranch::rewrite
Config::set_width_heuristics pretty much goes through all the width settings one by one and calls the get_width_value closure on each, leading to the error that you're seeing:
max_width = 100# Not strictly necessary to reproduce.single_line_if_else_max_width = 100# Any value above 92 produces the incorrect warning.
src/main.rs
macro_rules! anything {// Necessary to reproduce.() => {};}fnmain(){let v = if a == b {String::new()}else{format!("anything")};// Formatting does happen.}
The following incorrect warning is then displayed:
$ cargo fmt
`single_line_if_else_max_width` cannot have a value that exceeds `max_width`. `single_line_if_else_max_width` will be set to the same value as `max_width`
Although the project seems correctly formatted. Was this minimal reproductible example the only blocking point?
I just experienced the same problem and put a few print statements into the rustfmt source code, which revealed the following behaviour:
// max_width = 100// fn_call_width = 100macro_rules! foo {() => {// max_width = 92// fn_call_width = 100// WARNING: `fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`// Which results in:// fn_call_width = 92};}
Notice that rustfmt decreases max_width as it enters deeper scopes/nesting, but fn_call_width remains the same. I guess this saturation is actually desirable behaviour, but getting the context-less warning message causes more confusion than anything.
Interestingly, if you add an extra pair of brackets, max_width in the nested scope will be 96 instead of 92:
// max_width = 100// fn_call_width = 100macro_rules! foo {() => {{// max_width = 96// fn_call_width = 100// WARNING: `fn_call_width` cannot have a value that exceeds `max_width`. `fn_call_width` will be set to the same value as `max_width`// Which results in:// fn_call_width = 96}};}
Activity
ytmimi commentedon Jun 28, 2022
Thanks for the report!
Just as a heads up, when filing an issue please try to include a minimum code example that can be used to reproduce the issue along with any configuration options needed to produce the issue. It was a little tricky to track down since I tried running rustfmt on a few files and I couldn't reproduce the error until I ran rustfmt against
src/utils.rs. Doing so the error is emitted 4 times.Running rustfmt with debug logging enabled (
RUSTFMT_LOG=rustfmt=DEBUG rustfmt --config-path=issue_5404.toml --emit stdout src/utils.rs) reveals that this error is always emitted after callingreplace_names:replace_namesonly gets called inMacroBranch::rewriterustfmt/src/macros.rs
Lines 483 to 486 in c4416f2
And on line 1230 we adjust the
max_width, which is where the issue is occurring.rustfmt/src/macros.rs
Lines 1216 to 1230 in c4416f2
Config::setreturns aConfigSetter, and trying to set any of thewidthsettings results in callingConfig::set_heuristics.rustfmt/src/config/config_type.rs
Lines 89 to 103 in c4416f2
Config::set_heuristicscallsConfig::set_width_heuristics.rustfmt/src/config/config_type.rs
Lines 373 to 381 in c4416f2
Config::set_width_heuristicspretty much goes through all thewidthsettings one by one and calls theget_width_valueclosure on each, leading to the error that you're seeing:rustfmt/src/config/config_type.rs
Lines 294 to 314 in c4416f2
calebcartwright commentedon Jun 28, 2022
fwiw I know this has been reported before, but can't find the prior issues atm
tcharding commentedon Jun 28, 2022
Wow @ytmimi, thorough research/response, thank you. I'll add the minimal repro next time.
iago-lito commentedon Apr 25, 2023
Hi! I can also reproduce with the following:
.rustfmt.tomlsrc/main.rsThe following incorrect warning is then displayed:
Although the project seems correctly formatted. Was this minimal reproductible example the only blocking point?
ferdonline commentedon Oct 24, 2023
ytmimi commentedon Oct 24, 2023
ferdonline commentedon Oct 26, 2023
ytmimi commentedon Oct 26, 2023
bergkvist commentedon Feb 16, 2024
I just experienced the same problem and put a few print statements into the rustfmt source code, which revealed the following behaviour:
Notice that rustfmt decreases
max_widthas it enters deeper scopes/nesting, butfn_call_widthremains the same. I guess this saturation is actually desirable behaviour, but getting the context-less warning message causes more confusion than anything.Interestingly, if you add an extra pair of brackets, max_width in the nested scope will be 96 instead of 92:
fn_call_widthvs.max_widthfor default use_small_heuristics #6601 as a duplicate of this issuecsmulhern commentedon Sep 16, 2025
I have addressed this in #6651.
jieyouxu commentedon Nov 2, 2026
Reopening to track revert #7222 (#7223); we'll probably have to reland #6651 with a style edition gate.