Handle trailing comments on when entries in BlankLineBetweenWhenConditions

[jonapoul]

Description

I have a block of code in my project like below:

val x = when (something) {
    "a" -> 123 // Some comment
    "b" -> 456
    else -> 789
}

But this gave a linting problem with the new 1.8.0 update from the standard:blank-line-between-when-conditions rule. When I tried to auto-format to see how it should be, I got:

val x = when (something) {
    "a" -> 123
    
    // Some comment
    "b" -> 456

    else -> 789
}

The comment was placed on the wrong entry! Personally I think trailing comments should be allowable on simple when statements like this, interested to hear opinions on this though. The misformatting of the above example makes me think this is unintentional though.

To fix, I've added some more checks to isPrecededByComment to make sure the check for a multiline when entry handles this case.

No existing issue for this, so far as I can see.

Checklist

Before submitting the PR, please check following (checks which are not relevant may be ignored):

• Commit message are well written. In addition to a short title, the commit message also explain why a change is made.
• At least one commit message contains a reference Closes #<xxx> or Fixes #<xxx> (replace<xxx> with issue number)
• Tests are added
• KtLint format has been applied on source code itself and violations are fixed
• PR title is short and clear (it is used as description in the release changelog)
• PR description added (background information)

Documentation is updated. See difference between snapshot and release documentation

• Snapshot documentation in case documentation is to be released together with a code change
• Release documentation in case documentation is related to a released version of ktlint and has to be published as soon as the change is merged to master

[paul-dingemans]

Tnx for reporting and fixing.

The comment was placed on the wrong entry! Personally I think trailing comments should be allowable on simple when statements like this, interested to hear opinions on this though. The misformatting of the above example makes me think this is unintentional though.

EOL comments are always painful and causing problems. From the compiler perspective the EOL comment is at the same level as your literals "a" and "b". To match the expectation of the developer, rules quite often need additional logic to keep the EOL comment at the expected place. So this was definitely not the intended behavior. Unfortunately this was never reported while the rule was experimental (since Ktlint 1.2).