Skip to content

Fix wrong indenting with hard tabs in binop pairs#6883

Draft
matthewhughes934 wants to merge 1 commit intorust-lang:mainfrom
matthewhughes934:hard-tabs-issue-6859
Draft

Fix wrong indenting with hard tabs in binop pairs#6883
matthewhughes934 wants to merge 1 commit intorust-lang:mainfrom
matthewhughes934:hard-tabs-issue-6859

Conversation

@matthewhughes934
Copy link
Copy Markdown
Contributor

Note: opening as draft for a discussion. I'm not sure about the approach since there might be wide implications for all other callers of last_line_width


When rewriting pairs of multi-line binary operations, we would check the length of a line to see if we can snuggle the current line into the previous one. We compute the length of the previous line using last_line_width which is not aware of indentation widths (i.e. config.tab_spaces), so if we were formatting something like:

if some_long_name {
        foo
    } | if some_other_name {
        bar
    }

Then when we get to the line for | if some_other_name { we check the previous line, which is:

  • `\s\s\s\s\s\s\s\s}' if we are not using hard tabs (and 1 tab = 4 spaces), and
  • \t\t} if we are using hard-tabs

last_line_width would return 9 for the first one, and 3 for the second. Meaning if we're using hard tabs we could conclude that it should fit on the previous line, leading to inconsistent behaviour between the two.

To fix this, create a version of last_line_width that is aware of config.tab_spaces.

When rewriting pairs of multi-line binary operations, we would check the
length of a line to see if we can snuggle the current line into the
previous one. We compute the length of the previous line using
`last_line_width` which is not aware of indentation widths (i.e.
`config.tab_spaces`), so if we were formatting something like:

    if some_long_name {
            foo
        } | if some_other_name {
            bar
        }

Then when we get to the line for `| if some_other_name {` we check the
previous line, which is:

* `\s\s\s\s\s\s\s\s}' if we are not using hard tabs (and 1 tab = 4
  spaces), and
* `\t\t}` if we are using hard-tabs

`last_line_width` would return 9 for the first one, and 3 for the
second. Meaning if we're using hard tabs we could conclude that it
should fit on the previous line, leading to inconsistent behaviour
between the two.

To fix this, create a version of `last_line_width` that is aware of
`config.tab_spaces`.
@rustbot rustbot added the S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author. label May 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-author Status: awaiting some action (such as code changes or more information) from the author.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants