fn main/*comment*/() {
println!("Hello, world!");
}
After using cargo fmt:
fn main() {
println!("Hello, world!");
}
3 Likes
Yeah, there are a few cases where it does this.
struct /* comment */ MyObject {
}
$ cargo fmt
struct MyObject {
}
1 Like
I reported it on GitHub, a developer said they're not planned to fix it.
I assume you are referring to this comment? It just states that the issue has already been reported and that /* comments */ should not be placed in these locations until the bug is fixed.
To be fair, comments in that position are pretty unusual style. Do you need those comments specifically in those places? If not, you should move them to before or inside the function/struct definition.
1 Like
There's a case where this happens that I can't currently remember. I encounter it very rarely (2-3 times since I started using Rust several years ago), but it goes something like this:
somekeyword somemodifier identifier
And for some reason I have need to temporarily comment out the somemodifier, but when I do cargo fmt nukes it. It's trivial to fix (it's not a huge chunk of text it removes), but whenever it has happened I always think "Hey, give that back, I needed that!".
It never bothered me enough to report it, but I realize now after reading this thread that I should report it if it happens again.
2 Likes
I would agree that the comment on the linked issue could be formulated less discouraging. Encouraging users to “just write your code so it avoids the issue” as if that’s the most natural thing happening, can come across wrong, even more so if it’s implied that the user running into the issue was via some highly unnatural use-case or specifically crafted code, and not – even though that’s more likely – through some natural interaction that might have just been minimized for the error reporting. Rustfmt eating up comments is something I’m personally quite annoyed about every time it happens, and whilst I can understand that it might be a hard problem to fix from the developer’s point of view, it’s also terrible UX, especially for first-time encounters. If bad behavior from cargo fmt really is to be considered some kind of known/expected/low-priority-bug behavior, then perhaps it should do the same as cargo fix and require the user to save their state in version control before running a command that could potentially “break” their code?
I think deleting comments is, in my personal view, the second worst thing that rustfmt tends to do. The worst one being that it can break code in some reasonable cases that I was occasionally needing for testing rustc, and the third worst thing is that some IMO unfortunate style decisions are kept because of a AFAIK very strict stability policy of essentially (almost) never changing the formatting of code in newer rustfmt versions.
I’m pointing out these things, knowing that maintaining rustfmt is probably quite tedious, and I’m actually thankful for every contributor to an overall quite useful tool, so I want to make sure to sound not too harsh when complaining here; but we can always aspire to visions of a better future, and I’m looking forward to potential improvements that might come eventually.
E.g. dropped comments could perhaps somehow be detected after-the-fact in some kind of additional analysis over whole items, that undoes some formatting and emits a warning (apologizing and suggesting to move the comment elsewhere) whenever a comment got lost. Maybe this particular approach is or isn’t workable, but I believe there could be a principled solution, complementing the “true” but tedious and only incrementally-improving solution of fixing the (apparently fundamentally somewhat hard) issue of dropped comments in a case-by-case basis.
6 Likes
I didn't read the issue, and I'm not commenting on any interaction there.
However, in this case, it's pretty clear that the way this comment was written is niche and recommended against. I don't think "don't write weird code" is bad advice or should be discouraged.
Of course, I fully acknowledge that rustfmt deleting comments is and should be treated as a bug. But this doesn't change the fact that the kind of code that it erroneously altered shouldn't have been written in the first place.
1 Like
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.