Skip to content

Inconsistent function formatting when line matches max_width #6539

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
chrisduerr opened this issue Apr 13, 2025 · 0 comments
Open

Inconsistent function formatting when line matches max_width #6539

chrisduerr opened this issue Apr 13, 2025 · 0 comments

Comments

@chrisduerr
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant