I've found yet another bug. When AllowShortEnumsOnASingleLine is true and a multiline enum is forced (by line length, trailing comma, etc.), multiple names for the enum are placed on separate lines.
Mar 17 2021
Removed strlen call and added tests
Mar 16 2021
Mar 15 2021
Fixed remote build
Implemented requested changes
I would like to request that this commit be considered for merging.
Added comments for the previous commit's changes and cleaned up those changes
Mar 13 2021
Fixed AfterEnum's compatibility with AllowShortEnumsOnASingleLine
Mar 10 2021
If the bugs are (very) similar, I could live with one fix for both. Otherwise you should fix the other bug first, if its blocking this change.
Mar 8 2021
In my opinion you should then, either temporarily deactivate the test, or fix the bug first. A failing test blocks the pipeline and confuses everyone working on the project.
I hadn't had another look, because the CI still shows the test AfterEnum to be failing.
Mar 7 2021
Has anyone else had the chance to review this yet? (not trying to be pushy, just curious)
Jan 3 2021
The test still is there; Git is just showing the diff strangely. I didn't modify that test at all. The corner case bug doesn't affect FormatTest.ShortEnums because that test effectively has AfterEnum: false. Should I add cases for AfterEnum: true in that test too? I had figured the new test took care of that.
I don't understand; should every commit I've made be squashed into one and then submitted here?
AfterEnum: true currently overrides AllowShortEnumsOnASingleLine: true. If this is epxected behaviour then I'll modify the test to accomodate that, but otherwise, there's a separate issue.
Removed multiple enum names from new test
The first test fails due to the aforementioned corner case.
Added unit test
You need to have these conversations by adding new unit tests that prove your point, I highly doubt I'll personally be willing to accept any revision without more unit tests than this one line change
I think accepting a revision that includes only a fix for AfterEnum being ignored (not the corner case) and the new unit test would be the best way to go about this, since they're separate bugs. Then I can fix the corner case (and compatibility with the new unit test) in a separate differential.
OK, I'm getting a few more failed unit tests and I'm really not sure what correct formatting behaviour is anymore, so I'll just ask.
Jan 2 2021
Turns out the true/true bug goes quite deep. I've managed to resolve the first bit of it with a hack that I'm sure will warrant some criticism, but I haven't familiarised myself with this codebase enough to write a cleaner version.
After writing a unit test, I've found that a combination of AfterEnum: true and AllowShortEnumsOnASingleLine: true doesn't function properly even in release.. My next revision will include a fix for that alongside the unit test.
This seems to be that in "Attach" mode, then AllowShortEnumsOnASingleLine=false doesn't attach the brace.
Jan 1 2021
@MyDeveloperDay Would you mind explaining what changes you're wanting?
Dec 31 2020
Additionally, this bug has already been reported: https://bugs.llvm.org/show_bug.cgi?id=46927
@MyDeveloperDay I expect to see exactly that. clang-format currently does not respect AfterEnum, treating it as always true. This is why I changed UnwrappedLineParser.cpp.
Dec 30 2020
Changed commit username and email
Fixed the FormatTest.ShortEnums unit test and fixed compatibility with FormatTestCSharp.CSharpKeyWordEscaping and FormatTestJS.EnumDeclarations
The FormatTestJS.EnumDeclarations test in fact isn't broken, but FormatTest.ShortEnums
and FormatTestCSharp.CSharpKeyWordEscaping are.
From what I can tell the unit tests are broken. Take FormatTest.ShortEnums for example. It passes the following code: