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
Related to #6060 and #6044. For the below snippet, rustfmt does nothing at all:
enumFoo{A,B,C,D,}fnmain(){let foo = Foo::A;match foo {// Here is a commentFoo::A |
// And another oneFoo::B |
// Hey look! There's another oneFoo::C |
// That's a lot of commentsFoo::D => {}}}
If someone more knowledgeable about rustfmt internals can please confirm that this is a solvable bug, I'd be happy to contribute the fix.
When you try formatting this with error_on_unformatted=true configured, you'll get the following error message:
error[internal]: not formatted because a comment would be lost
--> <stdin>:10
|
10 | match foo {
|
= note: set `error_on_unformatted = false` to suppress the warning against comments or string literals
rustfmt isn't expecting to find comments within the OR pattern and would remove them if the code was formatted.
I'm not sure how simple this would be to solve. We usually use itemize_list to handle formatting lists of things internally, which takes care of rewriting comments as well.
It might be as simple as defining items (line 100) using itemize_list instead of mapping over the pat_strs, but I haven't looked into this.
I've played around with this in a few ways. The parser treats the first comment as a standalone comment, and the subsequent ones as "post-comments" for the preceding pattern. Using itemize_list() also does this, which means that a comment is joined into the same line as it's preceding pattern:
fnmain(){let foo = Foo::A;match foo {// Here is a commentFoo::A// And another one
| Foo::B// Hey look! There's another one
| Foo::C// That's a lot of comments
| Foo::D => {}}}
This breaks pretty badly when there is a multi-line comment, or just multiple single line comments. Tbh, I'm not even sure what the expected formatting would be, it can vary based on the placement of the | separator. I can't think of a good way forward to fix this. Maybe it's best to leave it as an unformattable instance?
Activity
ytmimi commentedon Mar 4, 2025
When you try formatting this with
error_on_unformatted=true
configured, you'll get the following error message:rustfmt isn't expecting to find comments within the OR pattern and would remove them if the code was formatted.
I'm not sure how simple this would be to solve. We usually use
itemize_list
to handle formatting lists of things internally, which takes care of rewriting comments as well.It might be as simple as defining
items
(line 100) usingitemize_list
instead of mapping over thepat_strs
, but I haven't looked into this.rustfmt/src/patterns.rs
Lines 90 to 117 in c6c8159
It's also likely that any change here would need to be gated.
If you're interested in working on this one you can comment
@rustbot claim
to assign yourself.snprajwal commentedon Mar 4, 2025
@rustbot claim
snprajwal commentedon Mar 18, 2025
I've played around with this in a few ways. The parser treats the first comment as a standalone comment, and the subsequent ones as "post-comments" for the preceding pattern. Using
itemize_list()
also does this, which means that a comment is joined into the same line as it's preceding pattern:This breaks pretty badly when there is a multi-line comment, or just multiple single line comments. Tbh, I'm not even sure what the expected formatting would be, it can vary based on the placement of the
|
separator. I can't think of a good way forward to fix this. Maybe it's best to leave it as an unformattable instance?snprajwal commentedon Mar 18, 2025
@rustbot release-assignment