False positive for 'Missing newline after "->" (indent)'

[lns-ross]

Observed Behavior

Linting the code below reports:

no_newline.kt:14:19: Missing newline after "->" (indent)

Steps to Reproduce

Use standard ktlint -v command on this code:

fun demo() {
    val list = listOf(1, 2, 3)

    // These are fine
    list.map { x ->
        /* A comment */
        println("Item: $x")
    }
    list.map { x -> /* A comment */
        println("Item: $x")
    }

    // This one shows the problem
    list.map { x ->
        /* A comment */ println("Item: $x")
    }
}

Your Environment

• Version of ktlint used: 0.43.2
• Kotlin: 1.6.10

[paul-dingemans]

Interesting example. The bug is reported at line 19 while the example only contains 18 line (including the blank after the closing brace). Without the comment on line 15, the error disappears.

[lns-ross]

no_newline.kt:14:19: Missing newline after "->" (indent)

Easy to mix up ... line 14, column 19
which is the '>'

[paul-dingemans]

no_newline.kt:14:19: Missing newline after "->" (indent)

Easy to mix up ... line 14, column 19 which is the '>'

Oops, missed that.

The interesting part of the example was however that the block comment lead to this result. Personally, I do think that using a block comment in this way should be avoided and that below should be preferred:

    list.map { x ->
        /* A comment of
         * multiple lines
         */
        println("Item: $x")
    }
    list.map { x ->
        // end of line comment
        println("Item: $x")
    }

I expect that block comments also will break other wrapping rules for the same reason. So I am wondering whether it might be better to have a new comment rule that forces block comments and KDocs to start and end on a line that does not contain any other code element.

[paul-dingemans]

So I am wondering whether it might be better to have a new comment rule that forces block comments and KDocs to start and end on a line that does not contain any other code element.

New experimental rules comment-wrapping and kdoc-wrapping are added in #1403. These will prevent the problem as construct below is not allowed anymore:

/* A comment */ println("Item: $x")

[lns-ross]

My one observation is that a single-line block comment is the ONLY way to add a comment at the beginning of the line. Not common but sometimes necessary/preferred. We don't use it often (usually only to tag a line as inserted/modified for debugging). In fact, the bug made the missed ones easier to find afterwards. :-)

Does disabling the new rule(s) (selectively or otherwise) also remove the false-positive in the indent rule? I didn't see an obvious resolution to that in the code of the PR. May be it was included as a fix in another PR?

Thanks for resolving this.

[paul-dingemans]

My one observation is that a single-line block comment is the ONLY way to add a comment at the beginning of the line.

True

Not common but sometimes necessary/preferred. We don't use it often (usually only to tag a line as inserted/modified for debugging). In fact, the bug made the missed ones easier to find afterwards. :-)

We seem to disagree on the necessary/preferred part ;-)

Does disabling the new rule(s) (selectively or otherwise) also remove the false-positive in the indent rule? I didn't see an obvious resolution to that in the code of the PR. May be it was included as a fix in another PR?

No, the error will still be there when the new rules are disabled. Solving this error would add unwanted complexity to the Indent Rule whcih already is bloated with lots of functionality.