Description
The problem occurs in the following code, note that the longest line is exactly 100 columns:
pub trait Manager {
fn attach_device(&self, seat_id: &str, sysfs_path: &str, interactive: bool) -> zbus::Result<()>;
}
If this is formatted with the 2021 edition, you get the following:
pub trait Manager {
fn attach_device(&self, seat_id: &str, sysfs_path: &str, interactive: bool)
-> zbus::Result<()>;
}
This isn't technically correct, since it shouldn't be broken at all, but at least the arrow is indented properly to make the association to the function clear.
With the 2024 edition, it formats like this:
pub trait Manager {
fn attach_device(&self, seat_id: &str, sysfs_path: &str, interactive: bool)
-> zbus::Result<()>;
}
So still breaks the line that doesn't need to be broken, but even worse than 2021 edition.
If the line is a single character longer, it's not broken at all:
pub trait Manager {
fn attach_device(&self, seat_id: &str, sysfs_path: &str, interactiv: bool) -> zbus::Result<()>;
}
If it is one character longer, the arguments are broken vertically:
pub trait Manager {
fn attach_device(
&self,
seat_id: &str,
sysfs_path: &str,
interactivee: bool,
) -> zbus::Result<()>;
}
Surely this can't be intentional? It seems like some sort of off-by-one error to me. I'd honestly be happier with having it broken apart vertically than that ugly 2024 formatting, even though it shouldn't require formatting at all.
Activity
ytmimi commentedon Jun 10, 2025
I think the "off by one" issue you've described here might be a distinct issue, at least I couldn't find anything for it with a quick search in the back log, but the 2024 issue is definitely a duplicate.
ytmimi commentedon Jun 10, 2025
Personally I'd want to limit the scope of this to just the "off by one" error described above. I did a little digging into this and I think I tracked down the source of the bug to this line of code:
rustfmt/src/items.rs
Lines 2605 to 2609 in 1443bba
The issue is that we're not accounting for cases where we don't have a body, or where the body is on the next line. I think the following change should resolve this if someone is interested in picking this up from where I left off and adding test cases:
[-]Inconsistent function formatting when line matches `max_width`[/-][+]Off By One: Return Type on Associated Function/Method wraps at exactly `max_width`[/+][-]Off By One: Return Type on Associated Function/Method wraps at exactly `max_width`[/-][+]Off by one: return type on associated function/method wraps at exactly `max_width`[/+]fix: wrap function without a body exceeding 100 characters (rust-lang…
lukewilson2002 commentedon Jun 15, 2025
Thanks for investigating the problem and proposing a fix. I added a test similar to the original issue, but I expect there may be more tests needed. I'll just wait on the advice of you or reviewers before I make it any more complicated.
fix: wrap function without a body exceeding 100 characters (rust-lang…