clang-format: Add AlignConsecutiveShortCaseStatements

[galenelias]

Summary

This resolves https://github.com/llvm/llvm-project/issues/55475.

This adds a new AlignConsecutiveShortCaseStatements option in line with the existing AlignConsecutive* options , which when AllowShortCaseLabelsOnASingleLine is enabled will align the tokens after the case statement's colon. This also adds a AlignCaseColons option to allow aligning the case label colon itself rather than the token after it.

For the implementation, I tried re-using AlignTokens, however went with a custom alignment method instead since consecutive case labels require traversing scopes (which AlignTokens doesn't allow). Additionally, special casing was required to allow empty case labels to not break the alignment sequence.

[HazardyKnusperkeks]

When I read the title I thought "Yay, some one is doing what I want and don't find the time.", but (for me) sadly you're not.
I'd like to align the colon (and thus the statement behind that). Do you think you can add that option too?

clang/include/clang/Format/Format.h

308

We need another name, you're not aligning the label, but the statement.

clang/unittests/Format/FormatTest.cpp

19206

19207

There is a verifyFormat overload which takes 2 strings, please use that.

19255

Add a test with AcrossEmptyLines and AcrossComments.

19256

Also add tests with SpaceBeforeCaseColon.

[galenelias]

In D151761#4385163, @HazardyKnusperkeks wrote:

When I read the title I thought "Yay, some one is doing what I want and don't find the time.", but (for me) sadly you're not.
I'd like to align the colon (and thus the statement behind that). Do you think you can add that option too?

Hmm, it had not occurred to me that there are folks who would want to insert the spaces after the 'case'. I can think about how that might be accomplished, but it doesn't seem straightforward given the current alignment infrastructure since the token you want to align (the colon) isn't the token which should be padded (the token after the case keyword). I think I'd have to write custom alignment code to allow for the separation of these two.

clang/include/clang/Format/Format.h

308

I was taking the name from the GitHub issue, which while I agree is a slight misnomer seemed to yield what I assumed most people would expect. I guess AlignConsecutiveStatementsAfterShortCaseLabels is more correct, but is also getting pretty verbose.

[MyDeveloperDay]

clang/docs/ClangFormatStyleOptions.rst

790

Did you generate this by hand or run the dump_format_style.py function? Format.h and the rst look out of sync

[galenelias]

clang/docs/ClangFormatStyleOptions.rst

790

This was generated from dump_format_style.py. What looks out of sync? My guess is the confusing thing is all the styles which use AlignConsecutiveStyle get the same documentation pasted for them which specifically references AlignConsecutiveMacros and makes it look like it's for the wrong option.

clang/unittests/Format/FormatTest.cpp

19255

There is a test for both AcrossEmptyLines and AcrossComments. Maybe I'm not understanding your comment?

[MyDeveloperDay]

clang/docs/ClangFormatStyleOptions.rst

790

that doesn't feel right to me.. not saying its not dump_format_style.py but it shouldn't do that in my view

[HazardyKnusperkeks]

In D151761#4385571, @galenelias wrote:

In D151761#4385163, @HazardyKnusperkeks wrote:

When I read the title I thought "Yay, some one is doing what I want and don't find the time.", but (for me) sadly you're not.
I'd like to align the colon (and thus the statement behind that). Do you think you can add that option too?

Hmm, it had not occurred to me that there are folks who would want to insert the spaces after the 'case'. I can think about how that might be accomplished, but it doesn't seem straightforward given the current alignment infrastructure since the token you want to align (the colon) isn't the token which should be padded (the token after the case keyword). I think I'd have to write custom alignment code to allow for the separation of these two.

After sleeping over it I want to revoke my request. Aligning the statements is sufficient, we don't need too much options. It just has to work with SpaceBeforeCaseColon, which I assume it already does.

clang/docs/ClangFormatStyleOptions.rst

790

What shouldn't it be doing?
The struct is used for multiple options and the documentation is that ways since we have the struct.

clang/include/clang/Format/Format.h

308

Maybe just AlignConsecutiveShortCaseStatements?

clang/unittests/Format/FormatTest.cpp

19195

Could you add test cases with not short cases between/at the begin of/at the end of the short ones?

19255

A test where both are true.

[HazardyKnusperkeks]

clang/unittests/Format/FormatTest.cpp

19217

19218

If both strings are the same, you only need to supply it once.

Or are they different and I can't see it?

19257

For what is this?

[galenelias]

Fixup up review comments.

[galenelias]

clang/unittests/Format/FormatTest.cpp

19206

I'll get used to adding full stops eventually... sorry for not catching this.

19218

They are the same, but I can't use the single string version, as that one calls test::messUp on the string which will strip blank lines, which then invalidates the test case. It seems pretty much all tests which are trying to validate behavior around empty spaces has to use the two string version.

19257

Oops, I was trying to set ColumnLimit = 0 before to stop it from merging multi-line case statements, but it wasn't working as expected, so I ended up inserting comments instead, and forgot to remove resetting this. Good catch!

[HazardyKnusperkeks]

Please wait for some other approval (or comments) for a few days.

clang/unittests/Format/FormatTest.cpp

19218

Check.

[MyDeveloperDay]

clang/docs/ClangFormatStyleOptions.rst

790

I understand why its there, I just don't like that the text is repeated and doesn't really reference the case statements, (it could be confusing).

for example what would PadOperators mean in this case

[MyDeveloperDay]

Apart from the documentation this looks fine.. thats probably outside the scope of this change

[MyDeveloperDay]

clang/docs/ClangFormatStyleOptions.rst

798

Do you think the documentation should give examples of the the other cases?

[MyDeveloperDay]

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

[galenelias]

clang/docs/ClangFormatStyleOptions.rst

790

I agree that it's confusing, I've actually gotten confused a few times while reading the documentation for various 'AlignConsecutive*' options. PadOperators and AlignCompound both explicitly state they only apply to AlignConsecutiveAssignments. Not sure what the fix would be, as this seems to be a fairly by design aspect of the struct sharing with regards to the documentation generation.

798

Hmm, I'm not sure what other cases? Cases where it doesn't align? In general, for the 'Align*' options we only show examples of the resulting formatting.

[galenelias]

In D151761#4394758, @MyDeveloperDay wrote:

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

That's a great point. I didn't really consider this, and currently this particular case won't align the case statements if they have an empty case block, however if you had some tokens (e.g. // fallthrough) it would. It's not immediately clear to me what the expectation would be. I guess to align as if there was an invisible trailing token, but it's a bit awkward if the cases missing a body are the 'long' cases that push out the alignment. Also, I don't think it's possible to use AlignTokens and get this behavior, as there is no token on those lines to align, so it's not straightforward to handle. I guess I'll be curious to see if there is feedback or cases where this behavior is desired, and if so, I can look into adding that functionality later. Since right now it would involve a completely custom AlignTokens clone, my preference would be to just leave this as not supported.

[HazardyKnusperkeks]

In D151761#4400056, @galenelias wrote:

In D151761#4394758, @MyDeveloperDay wrote:

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

That's a great point. I didn't really consider this, and currently this particular case won't align the case statements if they have an empty case block, however if you had some tokens (e.g. // fallthrough) it would. It's not immediately clear to me what the expectation would be. I guess to align as if there was an invisible trailing token, but it's a bit awkward if the cases missing a body are the 'long' cases that push out the alignment. Also, I don't think it's possible to use AlignTokens and get this behavior, as there is no token on those lines to align, so it's not straightforward to handle. I guess I'll be curious to see if there is feedback or cases where this behavior is desired, and if so, I can look into adding that functionality later. Since right now it would involve a completely custom AlignTokens clone, my preference would be to just leave this as not supported.

I'd say: align it.

[MyDeveloperDay]

In D151761#4400056, @galenelias wrote:

In D151761#4394758, @MyDeveloperDay wrote:

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

That's a great point. I didn't really consider this, and currently this particular case won't align the case statements if they have an empty case block, however if you had some tokens (e.g. // fallthrough) it would. It's not immediately clear to me what the expectation would be. I guess to align as if there was an invisible trailing token, but it's a bit awkward if the cases missing a body are the 'long' cases that push out the alignment. Also, I don't think it's possible to use AlignTokens and get this behavior, as there is no token on those lines to align, so it's not straightforward to handle. I guess I'll be curious to see if there is feedback or cases where this behavior is desired, and if so, I can look into adding that functionality later. Since right now it would involve a completely custom AlignTokens clone, my preference would be to just leave this as not supported.

Can you add a unit test with a // fallthough comment, and a /* FALLTHROUGH */ and [[fallthrough]] so we know whats going to happen in those cases at a minimum.

[galenelias]

In D151761#4400693, @HazardyKnusperkeks wrote:

In D151761#4400056, @galenelias wrote:

In D151761#4394758, @MyDeveloperDay wrote:

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

That's a great point. I didn't really consider this, and currently this particular case won't align the case statements if they have an empty case block, however if you had some tokens (e.g. // fallthrough) it would. It's not immediately clear to me what the expectation would be. I guess to align as if there was an invisible trailing token, but it's a bit awkward if the cases missing a body are the 'long' cases that push out the alignment. Also, I don't think it's possible to use AlignTokens and get this behavior, as there is no token on those lines to align, so it's not straightforward to handle. I guess I'll be curious to see if there is feedback or cases where this behavior is desired, and if so, I can look into adding that functionality later. Since right now it would involve a completely custom AlignTokens clone, my preference would be to just leave this as not supported.

I'd say: align it.

If it was straightforward, I would definitely agree to just align across empty case labels, but unfortunately there is no way to do that while using the generic AlignTokens (since the line with just a case has no token which matches the pattern, but needs to not break the alignment streak). I guess the way to do it generically would be to add some sort of ExcludeLine lambda to allow filtering out lines. Given that I don't think this is a common pattern with these 'Short Case Labels', and it's fairly easy to work around with [[fallthrough]]; my plan is just to leave this as is (and add a test to make the behavior explicit).

In D151761#4402568, @MyDeveloperDay wrote:

In D151761#4400056, @galenelias wrote:

In D151761#4394758, @MyDeveloperDay wrote:

did you consider a case where the case falls through? (i.e. no return)

"case log::info :    return \"info\";\n"
"case log::warning :\n"
"default :           return \"default\";\n"

That's a great point. I didn't really consider this, and currently this particular case won't align the case statements if they have an empty case block, however if you had some tokens (e.g. // fallthrough) it would. It's not immediately clear to me what the expectation would be. I guess to align as if there was an invisible trailing token, but it's a bit awkward if the cases missing a body are the 'long' cases that push out the alignment. Also, I don't think it's possible to use AlignTokens and get this behavior, as there is no token on those lines to align, so it's not straightforward to handle. I guess I'll be curious to see if there is feedback or cases where this behavior is desired, and if so, I can look into adding that functionality later. Since right now it would involve a completely custom AlignTokens clone, my preference would be to just leave this as not supported.

Can you add a unit test with a // fallthough comment, and a /* FALLTHROUGH */ and [[fallthrough]] so we know whats going to happen in those cases at a minimum.

Done. This actually caught an issue I wasn't aware of where if you use //fallthrough and the comment needs to be reflowed, you get two Change entries pointing to the same comment token, which throws off the algorithm, and results in broken alignment. Attempted to fix it up to ignore the inner reflow change and it seems to work in my basic validation.

[HazardyKnusperkeks]

In D151761#4403828, @galenelias wrote:

In D151761#4400693, @HazardyKnusperkeks wrote:

I'd say: align it.

If it was straightforward, I would definitely agree to just align across empty case labels, but unfortunately there is no way to do that while using the generic AlignTokens (since the line with just a case has no token which matches the pattern, but needs to not break the alignment streak). I guess the way to do it generically would be to add some sort of ExcludeLine lambda to allow filtering out lines. Given that I don't think this is a common pattern with these 'Short Case Labels', and it's fairly easy to work around with [[fallthrough]]; my plan is just to leave this as is (and add a test to make the behavior explicit).

Leaving it open (and documenting that) I could get behind, but making it explicit as desired behavior will not get my approval. On the other hand I will not stand in the way, if the others approve.

[galenelias]

In D151761#4404179, @HazardyKnusperkeks wrote:

In D151761#4403828, @galenelias wrote:

In D151761#4400693, @HazardyKnusperkeks wrote:

I'd say: align it.

If it was straightforward, I would definitely agree to just align across empty case labels, but unfortunately there is no way to do that while using the generic AlignTokens (since the line with just a case has no token which matches the pattern, but needs to not break the alignment streak). I guess the way to do it generically would be to add some sort of ExcludeLine lambda to allow filtering out lines. Given that I don't think this is a common pattern with these 'Short Case Labels', and it's fairly easy to work around with [[fallthrough]]; my plan is just to leave this as is (and add a test to make the behavior explicit).

Leaving it open (and documenting that) I could get behind, but making it explicit as desired behavior will not get my approval. On the other hand I will not stand in the way, if the others approve.

Yah, I think leaving it open would be my preference at this point. Not sure how to properly document that though? Just be explicit in the tests? Mention it in alignConsecutiveShortCaseStatements? Should it be documented in the generated documentation (that feels a bit heavy)?

[HazardyKnusperkeks]

In D151761#4410158, @galenelias wrote:

Yah, I think leaving it open would be my preference at this point. Not sure how to properly document that though? Just be explicit in the tests? Mention it in alignConsecutiveShortCaseStatements? Should it be documented in the generated documentation (that feels a bit heavy)?

It will be a known issue, and thus it should be documented explicitly in my opinion. Otherwise there will be bug reports. So I would do:

• Mention it in the options documentation.
• Add a FIXME comment where the fix most likely would be applied.
• Comment on test cases that they have to be changed once this is fixed - or add tests which are within an #if 0, don't know what @MyDeveloperDay or @owenpan like better.

[HazardyKnusperkeks]

After I came across some of my code, where I'd really like a feature like this, I'm back at wishing to align the colons. Same as in a bit field. And when you would do that I think there would be no open issue with empty statements, right?

So for my code I'd favor

switch (level) {
case log::info    : return "info:     ";
case log::warning : return "warning:  ";
case log::error   : return "error:    ";
case log::critical: return "critical: ";
default           : return "";
}

over

switch (level) {
case log::info:     return "info:     ";
case log::warning:  return "warning:  ";
case log::error:    return "error:    ";
case log::critical: return "critical: ";
default:            return "";
}

(For me actually there would always be at least one space before the colon.)
Maybe think about it?

[galenelias]

Ok, I added the ability to align the case label colons. In your original message you mentioned "I'd like to align the colon (and thus the statement behind that)" which implies actually adding the whitespace after the 'case' token itself. Not sure if that would still be your preference in an ideal world, or if I just misinterpreted your request. Aligning the colons themselves is very straightforward.

I opted to make this an option on AlignConsecutiveStyle, as that is consistent with how we customize some of the other AlignConsecutive* options, and it seemed awkward to add a floating top level boolean config option which applied to just this scenario - although it has the similar downside that it muddies the AlignConsecutiveStyle options for the other use cases.

[galenelias]

Well, I guess I didn't put quite enough thought into the AlignCaseColons option. While this solves the empty case label problem, it will also match in non-short case label scenarios such as the following, which doesn't seem desirable:

switch (level) {
case log::info  :
case log::error :
  return true;
case log::none     :
case log::warning  :
case log::critical :
  return false;
}

In order to solve this (and the other) issues, I think the only solution is to roll a custom alignment method instead of using AlignTokens, so that the alignment can be more correctly based on the detection of short case statements.

This is going to take considerably more time and code, so not sure when I'll be able to work on it.

[owenpan]

In D151761#4410998, @HazardyKnusperkeks wrote:

In D151761#4410158, @galenelias wrote:

Yah, I think leaving it open would be my preference at this point. Not sure how to properly document that though? Just be explicit in the tests? Mention it in alignConsecutiveShortCaseStatements? Should it be documented in the generated documentation (that feels a bit heavy)?

It will be a known issue, and thus it should be documented explicitly in my opinion. Otherwise there will be bug reports. So I would do:

• Mention it in the options documentation.
• Add a FIXME comment where the fix most likely would be applied.
• Comment on test cases that they have to be changed once this is fixed - or add tests which are within an #if 0, don't know what @MyDeveloperDay or @owenpan like better.

I prefer the latter, and IIRC @MyDeveloperDay doesn't use the former.

[HazardyKnusperkeks]

In D151761#4416224, @galenelias wrote:

Well, I guess I didn't put quite enough thought into the AlignCaseColons option. While this solves the empty case label problem, it will also match in non-short case label scenarios such as the following, which doesn't seem desirable:

switch (level) {
case log::info  :
case log::error :
  return true;
case log::none     :
case log::warning  :
case log::critical :
  return false;
}

In order to solve this (and the other) issues, I think the only solution is to roll a custom alignment method instead of using AlignTokens, so that the alignment can be more correctly based on the detection of short case statements.

This is going to take considerably more time and code, so not sure when I'll be able to work on it.

For me this would actually be desired. But from the name ShortCaseStatements I can see that it may be not what we want. This could be fixed with just renaming to ConsecutiveCaseStatements. :)

In D151761#4415755, @galenelias wrote:

Ok, I added the ability to align the case label colons. In your original message you mentioned "I'd like to align the colon (and thus the statement behind that)" which implies actually adding the whitespace after the 'case' token itself. Not sure if that would still be your preference in an ideal world, or if I just misinterpreted your request. Aligning the colons themselves is very straightforward.

I opted to make this an option on AlignConsecutiveStyle, as that is consistent with how we customize some of the other AlignConsecutive* options, and it seemed awkward to add a floating top level boolean config option which applied to just this scenario - although it has the similar downside that it muddies the AlignConsecutiveStyle options for the other use cases.

I have no problem with that, but the full disclosure is: @MyDeveloperDay isn't happy with e.g. PadOperators and thus will most likely not like this.

I think we need some input what should be able to be aligned - the statement vs. the colon - and only short case statements vs all case statements.

clang/include/clang/Format/Format.h

257

I'd also sort this alphabetically.

clang/lib/Format/WhitespaceManager.cpp

881

else after return can be dropped.

[owenpan]

In D151761#4418809, @HazardyKnusperkeks wrote:

I think we need some input what should be able to be aligned - the statement vs. the colon - and only short case statements vs all case statements.

I think we should align the colons only for short case statements and don't align if AllowShortCaseLabelsOnASingleLine is false.

[galenelias]

I re-wrote the alignment to stop using AlignTokens so that I can now handle all the edge cases that came up. Specifically:

• Allowing empty case labels (implicit fall through) to not break the alignment, but only if they are sandwiched by short case statements.
• Don't align the colon of a non-short case label that follows short case labels when using 'AlignCaseColons=true'.
• Empty case labels will also now push out the alignment of the statements when using AlignCaseColons=false.

Also, this now avoids having to add the IgnoreNestedScopes parameter to AlignTokens which didn't feel great.

I refactored AlignMacroSequence so I could re-use the core aligning method, since it's the same logic I need, but I removed some of the dead code just to simplify things along the way. But even with that, this version is quite a bit more code (~100 lines vs. ~30 lines).

[HazardyKnusperkeks]

In D151761#4474136, @galenelias wrote:

I re-wrote the alignment to stop using AlignTokens so that I can now handle all the edge cases that came up. Specifically:

• Allowing empty case labels (implicit fall through) to not break the alignment, but only if they are sandwiched by short case statements.
• Don't align the colon of a non-short case label that follows short case labels when using 'AlignCaseColons=true'.
• Empty case labels will also now push out the alignment of the statements when using AlignCaseColons=false.

Also, this now avoids having to add the IgnoreNestedScopes parameter to AlignTokens which didn't feel great.

I refactored AlignMacroSequence so I could re-use the core aligning method, since it's the same logic I need, but I removed some of the dead code just to simplify things along the way. But even with that, this version is quite a bit more code (~100 lines vs. ~30 lines).

Nice work!

clang/include/clang/Format/Format.h

311

Since you are not using AlignTokens anymore, I'd say use your own struct. You don't have the not used memberand you don't have to add a new member which is not used by AlignTokens.

clang/lib/Format/WhitespaceManager.cpp

116

Is this the right position?
Could you add a test with aligning assignments and case statements?

case XX: xx = 2; break;
case X: x = 1; break;

It should end up as

case XX: xx = 2; break;
case X:  x  = 1; break;

[galenelias]

clang/include/clang/Format/Format.h

311

Sure. Will post an iteration with this - hopefully I'm getting all the plumbing correct.

clang/lib/Format/WhitespaceManager.cpp

116

Great point, I hadn't actually really fully considered the ordering dependency here. I agree that aligning short case statements before assignments (and probably declarations?) seems more correct. However, these other alignConsecutive* methods don't actually align across scopes, so won't align declarations/assignments within the body of a case statement. I verified that these don't align today using AlignConsecutiveAssignments. I will however move this up to try to make it as logically correct as possible.

[galenelias]

This iteration switches away from using AlignConsecutiveStyle and instead uses a new ShortCaseStatementsAlignmentStyle.

[HazardyKnusperkeks]

clang/include/clang/Format/Format.h

391

I'd drop that. We don't have it for any other struct.

And with C++20 you don't need this anymore (although I don't know when llvm will switch to c++20).

clang/lib/Format/WhitespaceManager.cpp

116

Too bad, that would really be nice. :)
But certainly out of scope for this change.

clang/unittests/Format/ConfigParseTest.cpp

320

You now have to write your own checks for the parsing. (It's just copy & paste.)

[galenelias]

clang/include/clang/Format/Format.h

391

We do have it for TrailingCommentsAlignmentStyle and AlignConsecutiveStyle, but I will drop it.

clang/unittests/Format/ConfigParseTest.cpp

320

Aah, I had missed the CHECK_PARSE_NESTED_BOOLs for the existing alignConsecutive options within their macro. Will fix. Thanks

[galenelias]

Addressed outstanding review comments.

[HazardyKnusperkeks]

Thanks for the patience, I'm really looking forward to use this.

But please wait for other opinions.

[galenelias]

In D151761#4483050, @HazardyKnusperkeks wrote:

Thanks for the patience, I'm really looking forward to use this.

But please wait for other opinions.

Thanks so much @HazardyKnusperkeks for all the feedback and help. Out of curiosity, how long is typical to wait for additional opinions? I just want to make sure this doesn't get lost.

[owenpan]

FWIW, I think we can use a shorter name AlignConsecutiveCaseStatements instead of AlignConsecutiveShortCaseStatements.

clang/lib/Format/WhitespaceManager.cpp

881

No else after return.

886–887

Please remove the redundant parentheses.

936

940

clang/unittests/Format/FormatTest.cpp

19218

They are the same, but I can't use the single string version, as that one calls test::messUp on the string which will strip blank lines, which then invalidates the test case. It seems pretty much all tests which are trying to validate behavior around empty spaces has to use the two string version.

We have verifyNoChange for that now.

19232–19241

[galenelias]

In D151761#4524653, @owenpan wrote:

FWIW, I think we can use a shorter name AlignConsecutiveCaseStatements instead of AlignConsecutiveShortCaseStatements.

My only hesitation with that name is that it might seem like something like there should be some alignment being applied to 'normal' consecutive case statements, which there isn't. Maybe it's fine because the documentation makes it clear? I'm definitely not picky about the name, whatever sounds idiomatic. @HazardyKnusperkeks, thoughts on just AlignConsecutiveCaseStatements?

switch (level) {
case 0:
case 100:
   return "error";
}

[galenelias]

Addresses latest review comments.

[owenpan]

In D151761#4528389, @galenelias wrote:

In D151761#4524653, @owenpan wrote:

FWIW, I think we can use a shorter name AlignConsecutiveCaseStatements instead of AlignConsecutiveShortCaseStatements.

My only hesitation with that name is that it might seem like something like there should be some alignment being applied to 'normal' consecutive case statements, which there isn't. Maybe it's fine because the documentation makes it clear? I'm definitely not picky about the name, whatever sounds idiomatic. @HazardyKnusperkeks, thoughts on just AlignConsecutiveCaseStatements?

switch (level) {
case 0:
case 100:
   return "error";
}

Strictly speaking, case 0: in the example above is an empty case statement, so if we really want to be precise and verbose, we should use AlignConsecutiveNonEmptyCaseStatements or even AlignConsecutiveNonEmptyShortCaseStatements? I still prefer the shorter AlignConsecutiveCaseStatements, but will leave it to others.

[HazardyKnusperkeks]

All of those variants are fine by me, but I'd stick with the current version, because it is linked to AllowShortCaseLabelsOnASingleLine.

clang/docs/ClangFormatStyleOptions.rst

.. code-block:: c++
       false:
       a >>= 2;
       bbb = 2;
 
       a     = 2;
       bbb >>= 2;
 
 
+.. _AlignConsecutiveShortCaseStatements:
+
+**AlignConsecutiveShortCaseStatements** (``AlignConsecutiveStyle``) :versionbadge:`clang-format 17` :ref:`¶ <AlignConsecutiveShortCaseStatements>`
+  Style of aligning consecutive short case labels.
+  Only applies if ``AllowShortCaseLabelsOnASingleLine`` is ``true``.
+
+  ``Consecutive`` will result in formattings like:
+
+  .. code-block:: c++
+
+    case log::info:     return "info:";
+    case log::warning:  return "warning:";
+    default:            return "";
+
+  Nested configuration flags:
+
+  Alignment options.
+
+  They can also be read as a whole for compatibility. The choices are:
+  - None
+  - Consecutive
+  - AcrossEmptyLines
+  - AcrossComments
+  - AcrossEmptyLinesAndComments
+
+  For example, to align across empty lines and not across comments, either
+  of these work.
+
+  .. code-block:: c++
+
+    AlignConsecutiveMacros: AcrossEmptyLines
+
+    AlignConsecutiveMacros:
+      Enabled: true
+      AcrossEmptyLines: true
+      AcrossComments: false
+
+  * ``bool Enabled`` Whether aligning is enabled.
+
+    .. code-block:: c++
+
+      #define SHORT_NAME       42
+      #define LONGER_NAME      0x007f
+      #define EVEN_LONGER_NAME (2)
+      #define foo(x)           (x * x)
+      #define bar(y, z)        (y + z)
+
+      int a            = 1;
+      int somelongname = 2;
+      double c         = 3;
+
+      int aaaa : 1;
+      int b    : 12;
+      int ccc  : 8;
+
+      int         aaaa = 12;
+      float       b = 23;
+      std::string ccc;
+
+  * ``bool AcrossEmptyLines`` Whether to align across empty lines.
+
+    .. code-block:: c++
+
+      true:
+      int a            = 1;
+      int somelongname = 2;
+      double c         = 3;
+
+      int d            = 3;
+
+      false:
+      int a            = 1;
+      int somelongname = 2;
+      double c         = 3;
+
+      int d = 3;
+
+  * ``bool AcrossComments`` Whether to align across comments.
+
+    .. code-block:: c++
+
+      true:
+      int d    = 3;
+      /* A comment. */
+      double e = 4;
+
+      false:
+      int d = 3;
+      /* A comment. */
+      double e = 4;
+
+  * ``bool AlignCompound`` Only for ``AlignConsecutiveAssignments``.  Whether compound assignments
+    like ``+=`` are aligned along with ``=``.
+
+    .. code-block:: c++
+
+      true:
+      a   &= 2;
+      bbb  = 2;
+
+      false:
+      a &= 2;
+      bbb = 2;
+
+  * ``bool PadOperators`` Only for ``AlignConsecutiveAssignments``.  Whether short assignment
+    operators are left-padded to the same length as long ones in order to
+    put all assignment operators to the right of the left hand side.
+
+    .. code-block:: c++
+
+      true:
+      a   >>= 2;
+      bbb   = 2;
+
+      a     = 2;
+      bbb >>= 2;
+
+      false:
+      a >>= 2;
+      bbb = 2;
+
+      a     = 2;
+      bbb >>= 2;
+
+
 .. _AlignEscapedNewlines:
 
 **AlignEscapedNewlines** (``EscapedNewlineAlignmentStyle``) :versionbadge:`clang-format 5` :ref:`¶ <AlignEscapedNewlines>`
   Options for aligning backslashes in escaped newlines.
 
   Possible values:
 
   * ``ENAS_DontAlign`` (in configuration: ``DontAlign``)

clang/docs/ReleaseNotes.rst

- Add ``NextLineOnly`` style to option ``PackConstructorInitializers``.
   Compared to ``NextLine`` style, ``NextLineOnly`` style will not try to
   put the initializers on the current line first, instead, it will try to
   put the initializers on the next line only.
 - Add additional Qualifier Ordering support for special cases such
   as templates, requires clauses, long qualified names.
 - Fix all known issues associated with ``LambdaBodyIndentation: OuterScope``.
 - Add ``BracedInitializerIndentWidth`` which can be used to configure
   the indentation level of the contents of braced init lists.
+- Add ``AlignConsecutiveShortCaseStatements`` which can be used to align case
+  labels in conjunction with ``AllowShortCaseLabelsOnASingleLine``.
 
 libclang
 --------
 
 - Introduced the new function ``clang_CXXMethod_isExplicit``,
   which identifies whether a constructor or conversion function cursor
   was marked with the explicit identifier.
 

clang/include/clang/Format/Format.h

struct AlignConsecutiveStyle {
     bool operator!=(const AlignConsecutiveStyle &R) const {
       return !(*this == R);
     }
   };
 
   /// Style of aligning consecutive macro definitions.
   ///
   /// ``Consecutive`` will result in formattings like:
   /// \code
   ///   #define SHORT_NAME       42
   ///   #define LONGER_NAME      0x007f
   ///   #define EVEN_LONGER_NAME (2)
   ///   #define foo(x)           (x * x)
   ///   #define bar(y, z)        (y + z)
   /// \endcode
   /// \version 9
   AlignConsecutiveStyle AlignConsecutiveMacros;
struct FormatStyle {
   /// This will result in formattings like:
   /// \code
   ///   int         aaaa = 12;
   ///   float       b = 23;
   ///   std::string ccc;
   /// \endcode
   /// \version 3.8
   AlignConsecutiveStyle AlignConsecutiveDeclarations;
+  /// Style of aligning consecutive short case labels.
+  /// Only applies if ``AllowShortCaseLabelsOnASingleLine`` is ``true``.
+  ///
+  /// ``Consecutive`` will result in formattings like:
+  /// \code
+  ///   case log::info:     return "info:";
+  ///   case log::warning:  return "warning:";
+  ///   default:            return "";
+  /// \endcode
+  /// \version 17
+  AlignConsecutiveStyle AlignConsecutiveShortCaseStatements;
 
   /// Different styles for aligning escaped newlines.
   enum EscapedNewlineAlignmentStyle : int8_t {
     /// Don't align escaped newlines.
     /// \code
     ///   #define A \
     ///     int aaaa; \
     ///     int b; \
     ///     int dddddddddd;
     /// \endcode
     ENAS_DontAlign,
struct FormatStyle {
 
   /// Enums for AlignTrailingComments
   enum TrailingCommentsAlignmentKinds : int8_t {
     /// Leave trailing comments as they are.
     /// \code
     ///   int a;    // comment
     ///   int ab;       // comment
     ///
     ///   int abc;  // comment
     ///   int abcd;     // comment
     /// \endcode
     TCAS_Leave,
     /// Align trailing comments.
     /// \code
     ///   int a;  // comment
     ///   int ab; // comment
     ///

   bool operator==(const FormatStyle &R) const {
     return AccessModifierOffset == R.AccessModifierOffset &&
            AlignAfterOpenBracket == R.AlignAfterOpenBracket &&
            AlignArrayOfStructures == R.AlignArrayOfStructures &&
            AlignConsecutiveAssignments == R.AlignConsecutiveAssignments &&
            AlignConsecutiveBitFields == R.AlignConsecutiveBitFields &&
            AlignConsecutiveDeclarations == R.AlignConsecutiveDeclarations &&
            AlignConsecutiveMacros == R.AlignConsecutiveMacros &&
+           AlignConsecutiveShortCaseStatements ==
+               R.AlignConsecutiveShortCaseStatements &&
            AlignEscapedNewlines == R.AlignEscapedNewlines &&
            AlignOperands == R.AlignOperands &&
            AlignTrailingComments == R.AlignTrailingComments &&
            AllowAllArgumentsOnNextLine == R.AllowAllArgumentsOnNextLine &&
            AllowAllParametersOfDeclarationOnNextLine ==
                R.AllowAllParametersOfDeclarationOnNextLine &&
            AllowShortBlocksOnASingleLine == R.AllowShortBlocksOnASingleLine &&
            AllowShortCaseLabelsOnASingleLine ==

clang/lib/Format/Format.cpp

static void mapping(IO &IO, FormatStyle &Style) {
     IO.mapOptional("AlignArrayOfStructures", Style.AlignArrayOfStructures);
     IO.mapOptional("AlignConsecutiveAssignments",
                    Style.AlignConsecutiveAssignments);
     IO.mapOptional("AlignConsecutiveBitFields",
                    Style.AlignConsecutiveBitFields);
     IO.mapOptional("AlignConsecutiveDeclarations",
                    Style.AlignConsecutiveDeclarations);
     IO.mapOptional("AlignConsecutiveMacros", Style.AlignConsecutiveMacros);
+    IO.mapOptional("AlignConsecutiveShortCaseStatements",
+                   Style.AlignConsecutiveShortCaseStatements);
     IO.mapOptional("AlignEscapedNewlines", Style.AlignEscapedNewlines);
     IO.mapOptional("AlignOperands", Style.AlignOperands);
     IO.mapOptional("AlignTrailingComments", Style.AlignTrailingComments);
     IO.mapOptional("AllowAllArgumentsOnNextLine",
                    Style.AllowAllArgumentsOnNextLine);
     IO.mapOptional("AllowAllParametersOfDeclarationOnNextLine",
                    Style.AllowAllParametersOfDeclarationOnNextLine);
     IO.mapOptional("AllowShortBlocksOnASingleLine",
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.AlignConsecutiveAssignments.Enabled = false;
   LLVMStyle.AlignConsecutiveAssignments.AcrossEmptyLines = false;
   LLVMStyle.AlignConsecutiveAssignments.AcrossComments = false;
   LLVMStyle.AlignConsecutiveAssignments.AlignCompound = false;
   LLVMStyle.AlignConsecutiveAssignments.PadOperators = true;
   LLVMStyle.AlignConsecutiveBitFields = {};
   LLVMStyle.AlignConsecutiveDeclarations = {};
   LLVMStyle.AlignConsecutiveMacros = {};
+  LLVMStyle.AlignConsecutiveShortCaseStatements = {};
   LLVMStyle.AlignTrailingComments = {};
   LLVMStyle.AlignTrailingComments.Kind = FormatStyle::TCAS_Always;
   LLVMStyle.AlignTrailingComments.OverEmptyLines = 0;
   LLVMStyle.AllowAllArgumentsOnNextLine = true;
   LLVMStyle.AllowAllParametersOfDeclarationOnNextLine = true;
   LLVMStyle.AllowShortBlocksOnASingleLine = FormatStyle::SBS_Never;
   LLVMStyle.AllowShortCaseLabelsOnASingleLine = false;
   LLVMStyle.AllowShortEnumsOnASingleLine = true;

clang/lib/Format/WhitespaceManager.h

private:
   void alignConsecutiveBitFields();
 
   /// Align consecutive declarations over all \c Changes.
   void alignConsecutiveDeclarations();
 
   /// Align consecutive declarations over all \c Changes.
   void alignChainedConditionals();
 
+  /// Align consecutive short case statements over all \c Changes.
+  void alignConsecutiveShortCaseStatements();
+
   /// Align trailing comments over all \c Changes.
   void alignTrailingComments();
 
   /// Align trailing comments from change \p Start to change \p End at
   /// the specified \p Column.
   void alignTrailingComments(unsigned Start, unsigned End, unsigned Column);
 
   /// Align escaped newlines over all \c Changes.

clang/lib/Format/WhitespaceManager.cpp

if (Changes.empty())
     return Replaces;
 
   llvm::sort(Changes, Change::IsBeforeInFile(SourceMgr));
   calculateLineBreakInformation();
   alignConsecutiveMacros();
   alignConsecutiveDeclarations();
   alignConsecutiveBitFields();
   alignConsecutiveAssignments();
+  alignConsecutiveShortCaseStatements();
   alignChainedConditionals();
   alignTrailingComments();
   alignEscapedNewlines();
   alignArrayInitializers();
   generateChanges();
 
   return Replaces;
 }

 
 // Align a single sequence of tokens, see AlignTokens below.
 // Column - The token for which Matches returns true is moved to this column.
 // RightJustify - Whether it is the token's right end or left end that gets
 // moved to that column.
 template <typename F>
 static void
 AlignTokenSequence(const FormatStyle &Style, unsigned Start, unsigned End,
-                   unsigned Column, bool RightJustify, F &&Matches,
+                   unsigned Column, bool RightJustify, bool IgnoreNestedScopes,
+                   F &&Matches,
                    SmallVector<WhitespaceManager::Change, 16> &Changes) {
   bool FoundMatchOnLine = false;
   int Shift = 0;
 
   // ScopeStack keeps track of the current scope depth. It contains indices of
   // the first token on each scope.
   // We only run the "Matches" function on tokens from the outer-most scope.
   // However, we do need to pay special attention to one class of tokens
AlignTokenSequence(const FormatStyle &Style, unsigned Start, unsigned End,
   // Similar for broken string literals:
   //   double x = 3.14;
   //   auto s   = "Hello"
   //          "World";
   // Special handling is required for 'nested' ternary operators.
   SmallVector<unsigned, 16> ScopeStack;
 
   for (unsigned i = Start; i != End; ++i) {
-    if (ScopeStack.size() != 0 &&
+    if (!IgnoreNestedScopes && ScopeStack.size() != 0 &&
         Changes[i].indentAndNestingLevel() <
             Changes[ScopeStack.back()].indentAndNestingLevel()) {
       ScopeStack.pop_back();
     }
 
     // Compare current token to previous non-comment token to ensure whether
     // it is in a deeper scope or not.
     unsigned PreviousNonComment = i - 1;
     while (PreviousNonComment > Start &&
            Changes[PreviousNonComment].Tok->is(tok::comment)) {
       --PreviousNonComment;
     }
-    if (i != Start && Changes[i].indentAndNestingLevel() >
-                          Changes[PreviousNonComment].indentAndNestingLevel()) {
+    if (!IgnoreNestedScopes && i != Start &&
+        Changes[i].indentAndNestingLevel() >
       ScopeStack.push_back(i);
     }
 
     bool InsideNestedScope = ScopeStack.size() != 0;
     bool ContinuedStringLiteral = i > Start &&
                                   Changes[i].Tok->is(tok::string_literal) &&
                                   Changes[i - 1].Tok->is(tok::string_literal);
     bool SkipMatchCheck = InsideNestedScope || ContinuedStringLiteral;

 // alignment was already handled by the recursive invocations of this function.
 // However, the special exception is that we do NOT skip function parameters
 // that are split across multiple lines. See the test case in FormatTest.cpp
 // that mentions "split function parameter alignment" for an example of this.
 // When the parameter RightJustify is true, the operator will be
 // right-justified. It is used to align compound assignments like `+=` and `=`.
 // When RightJustify and ACS.PadOperators are true, operators in each block to
 // be aligned will be padded on the left to the same length before aligning.
+// The special processing of nested scopes can be disabled by passing
+// 'IgnoreNestedScopes', which is needed when aligning tokens which span scopes
+// such as case labels.
 template <typename F>
 static unsigned AlignTokens(const FormatStyle &Style, F &&Matches,
                             SmallVector<WhitespaceManager::Change, 16> &Changes,
                             unsigned StartAt,
                             const FormatStyle::AlignConsecutiveStyle &ACS = {},
-                            bool RightJustify = false) {
+                            bool RightJustify = false,
+                            bool IgnoreNestedScopes = false) {
   // We arrange each line in 3 parts. The operator to be aligned (the anchor),
   // and text to its left and right. In the aligned text the width of each part
   // will be the maximum of that over the block that has been aligned. Maximum
   // widths of each part so far. When RightJustify is true and ACS.PadOperators
   // is false, the part from start of line to the right end of the anchor.
   // Otherwise, only the part to the left of the anchor. Including the space
   // that exists on its left from the start. Not including the padding added on
   // the left to right-justify the anchor.
static unsigned AlignTokens(const FormatStyle &Style, F &&Matches,
   // Sequences start from the first matching token to align, and end at the
   // first token of the first line that doesn't need to be aligned.
   //
   // We need to adjust the StartOfTokenColumn of each Change that is on a line
   // containing any matching token to be aligned and located after such token.
   auto AlignCurrentSequence = [&] {
     if (StartOfSequence > 0 && StartOfSequence < EndOfSequence) {
       AlignTokenSequence(Style, StartOfSequence, EndOfSequence,
-                         WidthLeft + WidthAnchor, RightJustify, Matches,
-                         Changes);
+                         WidthLeft + WidthAnchor, RightJustify,
+                         IgnoreNestedScopes, Matches, Changes);
     }
     WidthLeft = 0;
     WidthAnchor = 0;
     WidthRight = 0;
     StartOfSequence = 0;
     EndOfSequence = 0;
   };
 
   unsigned i = StartAt;
   for (unsigned e = Changes.size(); i != e; ++i) {
-    if (Changes[i].indentAndNestingLevel() < IndentAndNestingLevel)
+    if (!IgnoreNestedScopes &&
+        Changes[i].indentAndNestingLevel() < IndentAndNestingLevel) {
       break;
+    }
 
     if (Changes[i].NewlinesBefore != 0) {
       CommasBeforeMatch = 0;
       EndOfSequence = i;
 
       // Whether to break the alignment sequence because of an empty line.
       bool EmptyLineBreak =
           (Changes[i].NewlinesBefore > 1) && !ACS.AcrossEmptyLines;
if (Changes[i].NewlinesBefore != 0) {
       LineIsComment = true;
     }
 
     if (!Changes[i].Tok->is(tok::comment))
       LineIsComment = false;
 
     if (Changes[i].Tok->is(tok::comma)) {
       ++CommasBeforeMatch;
-    } else if (Changes[i].indentAndNestingLevel() > IndentAndNestingLevel) {
+    } else if (!IgnoreNestedScopes &&
+               Changes[i].indentAndNestingLevel() > IndentAndNestingLevel) {
       // Call AlignTokens recursively, skipping over this scope block.
-      unsigned StoppedAt =
-          AlignTokens(Style, Matches, Changes, i, ACS, RightJustify);
+      unsigned StoppedAt = AlignTokens(Style, Matches, Changes, i, ACS,
+                                       RightJustify, IgnoreNestedScopes);
       i = StoppedAt - 1;
       continue;
     }
 
     if (!Matches(Changes[i]))
       continue;
 
     // If there is more than one matching token per line, or if the number of
AlignTokens(
         if (&C != &Changes.back() && (&C + 1)->NewlinesBefore > 0)
           return false;
 
         return C.Tok->is(TT_BitFieldColon);
       },
       Changes, /*StartAt=*/0, Style.AlignConsecutiveBitFields);
 }
 
+void WhitespaceManager::alignConsecutiveShortCaseStatements() {
+  if (!Style.AlignConsecutiveShortCaseStatements.Enabled)
+    return;
+
+  AlignTokens(
+      Style,
+      [&](Change const &C) {
+        return (C.Tok->SpacesRequiredBefore != 0 && C.Tok->Previous &&
+                C.Tok->Previous->is(TT_CaseLabelColon));
+      },
+      Changes, /*StartAt=*/0, Style.AlignConsecutiveShortCaseStatements,
+      /*RightJustify=*/false, /*IgnoreNestedScopes=*/true);
+}
+
 void WhitespaceManager::alignConsecutiveDeclarations() {
   if (!Style.AlignConsecutiveDeclarations.Enabled)
     return;
 
   AlignTokens(
       Style,
       [](Change const &C) {
         if (C.Tok->is(TT_FunctionDeclarationName))
           return true;
         if (C.Tok->isNot(TT_StartOfName))
AlignTokens(
                     C.Tok->Next->FakeLParens.back() != prec::Conditional)));
         },
         Changes, /*StartAt=*/0);
   } else {
     static auto AlignWrappedOperand = [](Change const &C) {
       FormatToken *Previous = C.Tok->getPreviousNonComment();
       return C.NewlinesBefore && Previous && Previous->is(TT_ConditionalExpr) &&
              (Previous->is(tok::colon) &&
               (C.Tok->FakeLParens.size() == 0 ||
                C.Tok->FakeLParens.back() != prec::Conditional));
     };
     // Ensure we keep alignment of wrapped operands with non-wrapped operands
     // Since we actually align the operators, the wrapped operands need the
     // extra offset to be properly aligned.
     for (Change &C : Changes)
       if (AlignWrappedOperand(C))
         C.StartOfTokenColumn -= 2;
     AlignTokens(
         Style,
         [this](Change const &C) {
           // Align question operators if next operand is not wrapped, as

clang/unittests/Format/ConfigParseTest.cpp

do {                                                                         \
     CHECK_PARSE_NESTED_BOOL(FIELD, AlignCompound);                             \
     CHECK_PARSE_NESTED_BOOL(FIELD, PadOperators);                              \
   } while (false)
 
   CHECK_ALIGN_CONSECUTIVE(AlignConsecutiveAssignments);
   CHECK_ALIGN_CONSECUTIVE(AlignConsecutiveBitFields);
   CHECK_ALIGN_CONSECUTIVE(AlignConsecutiveMacros);
   CHECK_ALIGN_CONSECUTIVE(AlignConsecutiveDeclarations);
+  CHECK_ALIGN_CONSECUTIVE(AlignConsecutiveShortCaseStatements);
 
 #undef CHECK_ALIGN_CONSECUTIVE
 
   Style.PointerAlignment = FormatStyle::PAS_Middle;
   CHECK_PARSE("PointerAlignment: Left", PointerAlignment,
               FormatStyle::PAS_Left);
   CHECK_PARSE("PointerAlignment: Right", PointerAlignment,
               FormatStyle::PAS_Right);

clang/unittests/Format/FormatTest.cpp

verifyFormat("const auto result{ []() {\n"
                BracedAlign);
   verifyFormat("int foo{ []() {\n"
                "  int bar{ 0 };\n"
                "  return 0;\n"
                "}() };",
                BracedAlign);
 }
 
+TEST_F(FormatTest, AlignConsecutiveShortCaseStatements) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AllowShortCaseLabelsOnASingleLine = true;
+  Alignment.AlignConsecutiveShortCaseStatements.Enabled = true;
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "default:           return \"default\";\n"
+               "}",
+               Alignment);
+
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               "switch (level) {\n"
+               "case log::info: return \"info\";\n"
+               "case log::warning:\n"
+               "  return \"warning\";\n"
+               "}",
+               Alignment);
+
+  // Verify comments and empty lines break the alignment
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "// comment\n"
+               "case log::critical: return \"critical\";\n"
+               "default:            return \"default\";\n"
+               "\n"
+               "case log::severe: return \"severe\";\n"
+               "}",
+               "switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "// comment\n"
+               "case log::critical: return \"critical\";\n"
+               "default:            return \"default\";\n"
+               "\n"
+               "case log::severe: return \"severe\";\n"
+               "}",
+               Alignment);
+
+  // Verify adjacent non-short case statements don't change the alignment, and
+  // properly break the set of consecutive statements.
+  verifyFormat("switch (level) {\n"
+               "case log::critical:\n"
+               "  // comment\n"
+               "  return \"critical\";\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "default:\n"
+               "  // comment\n"
+               "  return \"\";\n"
+               "case log::error:  return \"error\";\n"
+               "case log::severe: return \"severe\";\n"
+               "case log::extra_critical:\n"
+               "  // comment\n"
+               "  return \"extra critical\";\n"
+               "}",
+               Alignment);
+
+  Alignment.ColumnLimit = 80;
+  Alignment.SpaceBeforeCaseColon = true;
+  verifyFormat("switch (level) {\n"
+               "case log::info :    return \"info\";\n"
+               "case log::warning : return \"warning\";\n"
+               "default :           return \"default\";\n"
+               "}",
+               Alignment);
+  Alignment.SpaceBeforeCaseColon = false;
+
+  // Make sure we don't incorrectly align correctly across nested switch cases.
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "case log::other:\n"
+               "  switch (sublevel) {\n"
+               "  case log::info:    return \"info\";\n"
+               "  case log::warning: return \"warning\";\n"
+               "  }\n"
+               "  break;\n"
+               "case log::error: return \"error\";\n"
+               "default:         return \"default\";\n"
+               "}",
+               "switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "case log::warning: return \"warning\";\n"
+               "case log::other: switch (sublevel) {\n"
+               "  case log::info:    return \"info\";\n"
+               "  case log::warning: return \"warning\";\n"
+               "}\n"
+               "break;\n"
+               "case log::error: return \"error\";\n"
+               "default:         return \"default\";\n"
+               "}",
+               Alignment);
+
+  Alignment.AlignConsecutiveShortCaseStatements.AcrossEmptyLines = true;
+
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               "switch (level) {\n"
+               "case log::info: return \"info\";\n"
+               "\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               Alignment);
+
+  Alignment.AlignConsecutiveShortCaseStatements.AcrossComments = true;
+
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "\n"
+               "/* block comment */\n"
+               "\n"
+               "// line comment\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               "switch (level) {\n"
+               "case log::info: return \"info\";\n"
+               "\n"
+               "/* block comment */\n"
+               "\n"
+               "// line comment\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               Alignment);
+
+  Alignment.AlignConsecutiveShortCaseStatements.AcrossEmptyLines = false;
+
+  verifyFormat("switch (level) {\n"
+               "case log::info:    return \"info\";\n"
+               "//\n"
+               "case log::warning: return \"warning\";\n"
+               "}",
+               Alignment);
+}
+
 TEST_F(FormatTest, AlignWithLineBreaks) {
   auto Style = getLLVMStyleWithColumns(120);
 
   EXPECT_EQ(Style.AlignConsecutiveAssignments,
             FormatStyle::AlignConsecutiveStyle(
                 {/*Enabled=*/false, /*AcrossEmptyLines=*/false,
                  /*AcrossComments=*/false, /*AlignCompound=*/false,
                  /*PadOperators=*/true}));