chain-method-continution should take priority over argument-list-wrapping

[mklnwt]

chain-method-continution should take priority over argument-list-wrapping.

// Assume that the last
// allowed character is
// at the X character
// on the right             X
val foo = Bar.builder().baz(1).build()

Expected Rule behavior

val foo = Bar.builder()
    .baz(1)
    .build()

Current Behavior

val foo = Bar
    .builder()
    .baz(
        1,
    ).build()

Additional information

• Current version of ktlint: 1.1.0

[paul-dingemans]

I am not sure what the best order of those 2 rules is. Given code below:

                val foo1 = requireNotNull(bar.filter { it == "bar" }) { "some message" }
                val foo2 = requireNotNull(bar?.filter { it == "bar" }) { "some message" }

the expected outcome is:

                val foo1 = requireNotNull(
                    bar.filter { it == "bar" }
                ) { "some message" }
                val foo2 = requireNotNull(
                    bar?.filter { it == "bar" }
                ) { "some message" }

We need some smarter algorith do decide which rule takes precedence. But most like it will be hard to implement that without having breaking changes in the KtlintRuleEngine.

[mklnwt]

Best way would probably to check whether the chained call is within an argument or not.

Otherwise I agree, this could get very complex.

Would it be possible for an initial precedence to check if the parent of the chain is an assignment or a block.
Yes -> precedence
Not -> argument comes first

[paul-dingemans]

Would it be possible for an initial precedence to check if the parent of the chain is an assignment or a block.
Yes -> precedence
Not -> argument comes first

The order of the rules is defined before scanning starts. When you run ktlint CLI with --log-level=debug the order of the rules is printed.

Another complication is that a rule is not aware whether other rules are loaded or not (except when a rule has a declared dependency on another rule). If this information was available, the argument-list-wrapping rule could check if chain-method-continuation is enabled and take that into account when deciding to wrap the arguments in a method chain. This however is a breaking API change, and has to wait until Ktlint 2.0 is released (which might take a long time).

[rehevkor5]

Ktlint also produces formatting like this which I personally don't like but also doesn't seem to be backed up by the style guide:

.csrf { it.disable() }
.authorizeHttpRequests {
    // ...
}.oauth2ResourceServer { it ->
    // ...
}.build()

It should be like this instead:

.csrf { it.disable() }
.authorizeHttpRequests {
    // ...
}
.oauth2ResourceServer { it ->
    // ...
}
.build()

[paul-dingemans]

Ktlint also produces formatting like this which I personally don't like but also doesn't seem to be backed up by the style guide:

.csrf { it.disable() }
.authorizeHttpRequests {
    // ...
}.oauth2ResourceServer { it ->
    // ...
}.build()

It should be like this instead:

.csrf { it.disable() }
.authorizeHttpRequests {
    // ...
}
.oauth2ResourceServer { it ->
    // ...
}
.build()

Your remark is not related to original issue reported by OP. Please create your own issue, although it will be rejected as ktlint formatting will not be changed to the way you like it. Also, see https://pinterest.github.io/ktlint/latest/faq/#can-a-new-toggle-be-added-to-optionally-enabledisable-format-code-in-a-particular-way