This is an archive of the discontinued LLVM Phabricator instance.

[clang-format] De-duplicate includes with leading or trailing whitespace.
ClosedPublic

Authored by curdeius on Sep 25 2020, 5:57 AM.

Diff Detail

Event Timeline

curdeius created this revision.Sep 25 2020, 5:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 25 2020, 5:57 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
curdeius requested review of this revision.Sep 25 2020, 5:57 AM
curdeius edited the summary of this revision. (Show Details)Sep 25 2020, 5:58 AM
curdeius updated this revision to Diff 294291.Sep 25 2020, 6:02 AM
  • Ooops. Revert unwanted test changes.

Finally I've opted for creating a small revision just fixing this particular bug report.
Mind however that the problem is a bit more complex and to solve all possible cases we would need to first reformat the source code, then sort the includes and then again, possibly reformat parts of the source code modified by sorting, so that the comments get re-aligned etc.

MyDeveloperDay accepted this revision.Sep 25 2020, 7:37 AM

This LGTM, generally I think clang-format seems to remove trailing spaces anyway so it might be that the duplicate might disappear on the second format. but I'm good with this approach

But as a side note I keep wondering who are these people who clang-format once and expect it to be perfect!

Firstly I'm clang-format -n checking my 4-5 million lines of code every night, secondly the CI system is checking, and thirdly in our company we using clang-format on save, and Ctrl-S and :w are like a tick for me.

By the time I check my code in I've clang-formatted it 100's of times. I don't even need to use git clang-format I know its perfect already!

This is in my view the resolution to pretty much all those, I have to do it twice! bugs..its a non issue for anyone with a zero tolerance policy to un-clang-formtted code!

This revision is now accepted and ready to land.Sep 25 2020, 7:37 AM

Thanks for the review.
I agree with you that a clang-format user should not expect a perfectly formatted code after a single iteration.
Maybe it's actually a documentation issue and we should be clear about it? Just a guarantee of 1) stability of formatting and 2) asymptotically arriving at the fully formatted code.
I'll think about how to word it and create a revision for the documentation (unless you judge it unnecessary).

BTW, I would be almost inclined to abandon this review and mark the bug report as invalid... but the change is so trivial...

This revision was landed with ongoing or failed builds.Dec 3 2020, 2:00 AM
This revision was automatically updated to reflect the committed changes.