Adds an option to [clang-format] which sorts headers in an alphabetical manner using case only for tie-breakers. The options is off by default in favor of the current ASCIIbetical sorting style.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I'll work on fixing the unit tests. Thought they ran with check-clang-format but I was obviously wrong.
Please expand the test case to different options like grouping. Otherwise looks good.
@HazardyKnusperkeks let me know if the additions to the unit test are along the lines you were hoping for or not, I think this captures what you had in mind.
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2354 | The name is somewhat awkward IMO (in the sense it doesn't read nicely), but it's nice to be (alphabetically) closer to other Include-related options in the documentation. | |
2360 | I'd write this in the same manner as other options, so sth like "When false: <code>... When true: <code>". Otherwise, it's necessary to read up to the end of the description "This option is off by default" and conclude that off=false and that was the first snippet that corresponded to false. | |
clang/lib/Format/Format.cpp | ||
2241 | Maybe it would be better for CodeGen to get the if outside of sort? It would mean some code duplication, but maybe it could be mitigated with a lambda. | |
clang/unittests/Format/SortIncludesTest.cpp | ||
602 | You should test that this option is false for LLVM style. |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2354 | I agree how about IncludeSortCaseSensitive |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2354 | I went with IncludeSortAlphabetically for now. To me, this reads better and seems to more clearly indicate the effect of turning this on. The downside is it no longer captures the fact that case does still play a part in the sort. What do you both think? | |
2360 | Good call, I definitely agree. I've rewritten this to better match the bool flag instances. | |
clang/lib/Format/Format.cpp | ||
2241 | This is a good point. I moved the if outside of the call to stable_sort. I don't feel there is actually much code duplication caused by this (other than the call signature). |
LGTM. Thanks for being prompt at addressing the comments. I'll merge it today for you if @MyDeveloperDay has no more remarks.
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 | Are you sure IncludeSortAlphabetically expresses what you mean? Once these things get released they cannot be changed easily. If you were not sure of a new option, in my view we should slow down and make sure we have the correct design, for example you could have used a enum and it might have given you more possibility for greater flexibility enum IncludeSort { CaseInsensitive CaseSensitive } Please give people time to re-review your changes before we commit, especially if they've taken the time to look at your review in the first place. Just saying. |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 | Hi, @MyDeveloperDay I definitely agree. It was not my intention to rush through the review. I was simply trying to follow the process outlined in https://llvm.org/docs/Contributing.html#how-to-submit-a-patch which mentions giving sufficient information to allow for a commit on your behalf when you don't have access after an LGTM (which is all that I did). As you can see from the lack of additional comments from my end, I was happy to let this sit and be reviewed. Per the discussion about the option itself, I do believe IncludeSortAlphabetically currently expresses what I mean as the behavior with this off is indeed not an alphabetical sort as case takes precedence over the alphabetical ordering. However, looking at the enum and realizing that others probably will have additional styles they prefer (maybe they want alphabetical but lower case first, etc.) I do believe it might have been a better way to go as it leaves more flexibility and room for additional ordering styles. Given that this just landed, I would be happy to open a patch to turn this into an enum as I do see benefits to doing so. What do you think? |
Reverting would also be fine with me. I am happy to drive towards a feature (and flags) that everyone is comfortable with in whichever way makes the most sense.
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 | Hmmm, and how about using the existing option SortIncludes and change its type from bool to some enum? This will have the advantage of not adding additional style options. |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 | I also fully support that! (Although I would not say a bool is per se bad.) |
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 | @curdeius @MyDeveloperDay @HazardyKnusperkeks this is now done. However... The command-line option (--sort-includes) is not in a place that I like at the moment but I am having trouble thinking of any really good options. The issue as it stands is that there are a lot of usages of the flag that assume it is a bool and therefore sometimes do not pass any value. These of course could be updated along with the flag to accept a std::string value, however, this breaks backward capability for anyone relying on that flag not requiring a value. As I have it now, backward compatibility is maintained but the command line flag is rather severely limited compared to the configuration option. Thoughts on which path to take? A third option I have not considered? |
clang/lib/Format/Format.cpp | ||
---|---|---|
426 | Is this needed? |
clang/lib/Format/Format.cpp | ||
---|---|---|
426 | Ok. You just fixed it. |
Concerning the --sort-includes command-line flag. I'd rather keep it as is and, if need be, work on accepting an optional string argument.
Please update release notes.
clang/docs/ClangFormatStyleOptions.rst | ||
---|---|---|
2355 |
@HazardyKnusperkeks, I was of course a bit exaggerating :). |
@curdeius Just to confirm, are you asking for the "commit" message to be updated or something else?
I was thinking of https://github.com/llvm/llvm-project/blob/main/clang/docs/ReleaseNotes.rst#clang-format. Look at the history to see how it was written before.
Also, you may change the revision title if you want (it will become the commit message).
I find the naming of the case sensitive options confusing here.
When I read "CaseSensitive" I think of the behavior of strcmp() which sorts according to "ASCIIbetical" order. But here "CaseSensitive" throws away case by comparing the result of "Filename.lower()" which I would consider case-insensitive, or the same behavior as a call to stricmp().
Do you have an idea for better names?
I see that e.g. MS documentation uses ascending order and case-sensitive order.
I'm okay with the names, it just seems to me that they are reversed, where CaseSensitive should sort using ASCIIbetic order, and CaseInsensitive should ignore case entirely in the same way that most case-insensitive string compares would.
After initially reading it I was not sure about it, but now I have looked into the wikipedia:
In computers, case sensitivity defines whether uppercase and lowercase letters are treated as distinct (case-sensitive) or equivalent (case-insensitive).
So I would support a name switch. I would wait a few days for @kentsommer to say something, if he doesn't respond just make a diff and add me as reviewer. :)
Do you make a change? Otherwise I will do, but that will take some time, because I'm rather busy.
Do you make a change? Otherwise I will do, but that will take some time, because I'm rather busy.
Sorry, I have not; unfortunately I've been rather busy myself and haven't had a moment to get on it.
The name is somewhat awkward IMO (in the sense it doesn't read nicely), but it's nice to be (alphabetically) closer to other Include-related options in the documentation.
I have no better name though. Just noticing.