Fix OneCasePerLine stranding the case keyword on its own line

[adityasingh2400]

Fixes #1009.

When a multi-element case declaration has its elements spread across continuation lines, OneCasePerLine left the leading newline trivia on each element's name when splitting them into separate declarations. With respectsExistingLineBreaks enabled (the default), the pretty printer honored that newline, so the case keyword ended up alone on its own line:

public enum TestEnum: Int {
  case a = 0,
    b = 1,
    c = 2
}

was reformatted to

public enum TestEnum: Int {
  case a = 0
  case
    b = 1
  case
    c = 2
}

Fix

When building each generated case declaration, drop the leading vertical whitespace (newlines and surrounding indentation) from its first element so the element stays on the same line as the case keyword. Comments attached to the element are preserved rather than dropped, so something like

case a = 1,
  // keep with b
  b = 2

still keeps the comment with b.

Testing

Added testElementsOnContinuationLinesAreMovedOntoCaseKeyword covering the reported case and testCommentBetweenElementsOnContinuationLinesIsPreserved for the comment edge case. swift test passes (915 tests, the one pre-existing skip unchanged).

[allevato]

I think in this situation, we could do even better: Move the comment/trivia to precede the newly inserted case keyword.

Another question: What if the comment is an end-of-line comment on the previous line, like this?

enum Foo: Int {
  case a = 1,  // a comment about 'a'
    b = 2
}

In that case, since the comment is at the end of the line associated with a, it should stay on that line. Can you add a test for that as well and make sure it behaves as described?

[adityasingh2400]

Good calls on both, thanks. I pushed a revision.

For the documentation comment that lives on its own continuation line, I now hoist it so it precedes the newly inserted case keyword instead of leaving it stranded between case and the binding. So your earlier example splits to:

case a = 1
// This should stay with `b`.
case b = 2

For the end-of-line comment case you raised, that comment sits in the trailing trivia of the previous binding's comma, and the rule was dropping it when it stripped the comma. I now carry that trailing trivia over onto the element before removing the comma, so it stays on the same line as the binding it follows:

case a = 1,  // a comment about 'a'
  b = 2

becomes

case a = 1  // a comment about 'a'
case b = 2

I added a test for that (testEndOfLineCommentStaysWithItsElement), updated the earlier test to assert the comment now moves ahead of case, and added one more covering both kinds of comment on a single split so they each end up in the right place. swift test --filter OneCasePerLine passes locally and the changed files lint clean under --strict.

[allevato]

Thanks!