Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indentation issue for safe-called wrapped trailing lambdas #776

Closed
jzbrooks opened this issue Jun 9, 2020 · 1 comment · Fixed by #785
Closed

Indentation issue for safe-called wrapped trailing lambdas #776

jzbrooks opened this issue Jun 9, 2020 · 1 comment · Fixed by #785
Labels
Milestone

Comments

@jzbrooks
Copy link

jzbrooks commented Jun 9, 2020

Expected Behavior

For curly braces, put the opening brace in the end of the line where the construct begins, and the closing brace on a separate line aligned horizontally with the opening construct.

https://kotlinlang.org/docs/reference/coding-conventions.html#formatting

I expect braces to be aligned with their opening construct, taking into account continuation indentation.

Observed Behavior

The opening construct seems to be evaluated as the imageUrls declaration, but the brace belongs with the map function call. This issue only seems to happen with this particular indentation in tandem with safe-call operators.

diff --git a/app/src/main/kotlin/com/faithlife/mobile/feedback/FeedbackViewModel.kt b/app/src/main/kotlin/com/faithlife/mobile/feedback/FeedbackViewModel.kt
index e642c4ca..d66ae436 100644
--- a/app/src/main/kotlin/com/faithlife/mobile/feedback/FeedbackViewModel.kt
+++ b/app/src/main/kotlin/com/faithlife/mobile/feedback/FeedbackViewModel.kt
@@ -54,8 +54,8 @@ class FeedbackViewModel @Inject constructor(
            val imageUrls = stagedImages.value
                 ?.filter {
                     it.image.remoteUri != null
                 }?.map {
-                    it.image.remoteUri!!
-                }
+                it.image.remoteUri!!
+            }
 
             repository.sendFeedback(description, hardwareId, imageUrls)
         }

A case can be made that the ?.map call should be wrapped to the next line, and that's fine, but this indentation seems clearly awkward to me. If the wrapping of the map method is the rub, then ktlint should auto format that as well.

Steps to Reproduce

Run ktlint on the following code. Observe the awkward indentation and the different in output bar is made non-nullable.

val bar: List<Integer>? = listOf(1, 2, 3, 4)

val foo = bar
    ?.filter { number ->
        number % 2 == 0
    }?.map { evenNumber ->
        evenNumber * evenNumber
    }

Your Environment

  • Version of ktlint used: 0.37.1
  • Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task):
    val commonArgs = arrayOf(
        "--android",
        "--reporter=plain?group_by_file",
        "src/**/*.kt",
        "**/*.gradle.kts"
    )

    val ktlint by registering(JavaExec::class) {
        group = "verification"
        description = "Check Kotlin code style."
        classpath = configurations.getByName("ktlint")
        main = "com.pinterest.ktlint.Main"
        args(*commonArgs)
    }

    val ktlintFormat by registering(JavaExec::class) {
        group = "formatting"
        description = "Fix Kotlin code style deviations."
        classpath = configurations.getByName("ktlint")
        main = "com.pinterest.ktlint.Main"
        args("--format", *commonArgs)
    }
  • Version of Gradle used (if applicable): 6.4.1
  • Operating System and version: macOS 10.15.5
  • Link to your project (if it's a public repository): It's a commercial, closed-source project.
@Tapchicoma Tapchicoma added the bug label Jun 9, 2020
@Tapchicoma Tapchicoma added this to the 0.38.0 milestone Jun 9, 2020
@shashachu
Copy link
Contributor

thanks for the detailed bug report! we'll take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants