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

Infix function confuses the indent rule #897

Closed
androa opened this issue Sep 10, 2020 · 4 comments
Closed

Infix function confuses the indent rule #897

androa opened this issue Sep 10, 2020 · 4 comments

Comments

@androa
Copy link

androa commented Sep 10, 2020

Expected Behavior

I'm writing a DSL for expressing some rules, and use a lot of infix functions.

If write the following:

val rules = "rule1".all(
    "subrule1".all(
        date1 notBefore date2,
    )
).then(
    "subrule2".all(
        date3 notBefore date4
    )
) or "rule1".all(
    date4 notBefore date6
)

everything works as expected. If I use the infix then ktlint becomes confused

val rules = "rule1".all(
    "subrule1".all(
        date1 notBefore date2,
    )
) then(
    "subrule2".all(
        date3 notBefore date4
    )
) or "rule1".all(
    date4 notBefore date6
)

Observed Behavior

ktlint can't decide on how much it wants to indent the three last lines. It just keeps sending me around fixing it back and forth from 0 -> 4 -> 8 -> 4 -> 8 -> 4 -> 8 and so forth

ktlint --verbose says:

File.kt:48:5: Unexpected indentation (expected 8, actual 4) (parameter-list-wrapping)
File.kt:49:1: Unexpected indentation (expected 4, actual 0) (parameter-list-wrapping)

Your Environment

  • Version of ktlint used: 0.38.1
@Tapchicoma Tapchicoma added the bug label Sep 10, 2020
@Tapchicoma Tapchicoma added this to the 0.40.0 milestone Sep 10, 2020
@Tapchicoma Tapchicoma modified the milestones: 0.40.0, 0.41.0 Dec 5, 2020
@abubics
Copy link

abubics commented May 31, 2021

I'm in a similar situation, but the symptoms are a little more deterministic (so I hope the extra detail helps narrow anything down).

I'm using Exposed, which likewise has an infix-heavy DSL, and sometimes needs brackets for readability.

When trying a long chained expression like this:

AmendmentTable
  .innerJoin(PlanningSchemeAmendmentTable)
  .innerJoin(PlanningSchemeTable)
  .select {
    (PlanningSchemeTable.code eq schemeCode) and (
      (AmendmentTable.exhibitionStartDate eq null) or
        (AmendmentTable.exhibitionStartDate lessEq now())
    )
  }

the infix fun and causes ktlint issues with its closing bracket (wanting to be indented an extra step).

Changing it to

    (PlanningSchemeTable.code eq schemeCode).and(

(no longer infix) removes the reported violation.

Also, indenting it as advised removes the violation, unlike the above reported issue (where it alternates between errors).

Your Environment

  • ktlint version: 0.41.0? It's not clear from the gradle plugin, and doesn't appear in gradle dependencies.
  • Integration: org.jlleitschuh.gradle.ktlint - 10.0.0
  • Gradle: 7.0.1

@paul-dingemans
Copy link
Collaborator

I do agree with both of you, that the formatting of the examples above is not what you expect. Despite that, it can not be considered as a bug in ktlint. Analog to IntelliJ IDEA, ktlint formats binary expressions between parentheses in this way. From ktlint code (IndentationRule):

            // IDEA quirk:
            // val v = (
            //     true
            //     )
            // instead of expected
            // val v = (
            //     true
            // )
            nextLeafElementType == RPAR &&
                node.treeParent?.elementType == PARENTHESIZED ->
                0

If you disable the ktlint plugin in IntelliJ and reformat the code sample above, the formatted code is comparable with the result of ktlint.

@abubics
Copy link

abubics commented Nov 8, 2021

I'm not using IntelliJ for ktlint, but that's interesting.

androa's original issue still sounds like a bug, because running ktlint multiple times gives inconsistent results ("0 -> 4 -> 8 -> 4 -> 8 -> 4 -> 8 and so forth").

@paul-dingemans
Copy link
Collaborator

Closed by #1284

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

No branches or pull requests

5 participants