Last Condition Comment is formatted as the Execution Block Comment

[davidBar-On]

Input

fn main() {
    /* comments before the if statement */
    if condition1 /* condition 1 explanations */
        && condition2 /* condition 2 explanations */
        && condition3 /* condition 3 explanations */
    /* comments to the executed block */
    {
        x = 5;
    }
}

fn main() {
    /* comments before the if statement *
     * with second line */
    if condition1 /* condition 1 explanations *
                   * with second line */
        && condition2 /* condition 2 explanations *
                       * with second line */
        && condition3 /* condition 3 explanations *
                       * with second line */
    /* comments to the executed block *
     * with second line */
    {
        x = 5;
    }
}

Output

fn main() {
    /* comments before the if statement */
    if condition1 /* condition 1 explanations */
        && condition2 /* condition 2 explanations */
        && condition3
    /* condition 3 explanations */
    /* comments to the executed block */
    {
        x = 5;
    }
}

fn main() {
    /* comments before the if statement *
     * with second line */
    if condition1 /* condition 1 explanations *
                   * with second line */
        && condition2 /* condition 2 explanations *
                       * with second line */
        && condition3
    /* condition 3 explanations *
     * with second line */
    /* comments to the executed block *
     * with second line */
    {
        x = 5;
    }
}

Expected output
No change to the input. That is, the comment to condition3 should remain in the same line of the condition when line is not too long. ( Test cases are based on PR #4518 test cases.)

Is this a real issue or this is the expected formatting? If this is an issue than the following two approaches may be taken:

1. Put the first (condition) comment in the same line with the condition or in new line based on on whether the comment is in the same or new line in the original code.

2. As it is seem difficult to know whether a second comment after a condition is for the condition or for the execution block (it is always in new line so requires consideration of original indentation), always consider a second comment after a condition as a comment for the block and not for the condition (same approach for second comment may also fix issue A comment under struct field exceeds max width #2201). That is:

        && condition3 // condition 3 explanations
                      // Second line comment for condition 3
    /* comments to the executed block */

Will be formatted as:

        && condition3 // condition 3 explanations
    // Second line comment for condition 3
    /* comments to the executed block */

Meta

• rustfmt version: rustfmt 2.0.0-rc.2-nightly (30bda450 2020-11-18)
• From where did you install rustfmt?: self build

[calebcartwright]

Is this a real issue or this is the expected formatting? If this is an issue than the following two approaches may be taken

Personally, I feel like this is expected or at least acceptable given the tradeoffs. This strikes me as a rather extreme edge case, and barring any significant real world impact, I don't think there is anything to be changed here.

Yes, technically rustfmt could reach back into associated spans of the original snippet to try to determine whether a comment between the condition expression and block starts on the same line and use that to try to interpret association and determine indentation, but there would still be some weird/gray areas that would prevent any absolute certainty from being possible (e.g. first line of multi-line comment starting on same line as end of cond. expression but opening brace on the same line as the final line of that same multi-line comment).

However, attempting to do any of that would add undo complexity and performance hits on rustfmt itself for something that's tough to picture really happening. In the event of a conditional really needing complex multiline comments, one would imagine that would be best written as a single cohesive block before the expression itself. Even in the more extreme case of needing multi-line comments on individual operands, then I'd argue those would be better written as preceeding comments above their respective operands similar to how doc comments are written as opposed to trailing same-line starting comments.

[davidBar-On]

OK. Closing the issue.