Strange line splitting choice for logical operator

[jdm]

Before:

    disallowed_headers.iter().any(|header| *header == name) ||
        disallowed_header_prefixes.iter().any(|prefix| name.starts_with(prefix))

After:

    disallowed_headers.iter().any(|header| *header == name) || disallowed_header_prefixes
        .iter()
        .any(|prefix| name.starts_with(prefix))

[nrc]

Adding to milestone for investigation. I suspect it won't be easy to fix this though.

[jdm]

This is another interesting case I discovered.
Before:

            (root.is_parent_of(elem.upcast())
                || self.sections.iter().any(|ref section| section.is_parent_of(elem.upcast())))

After:

            (root.is_parent_of(elem.upcast()) || self
                .sections
                .iter()
                .any(|ref section| section.is_parent_of(elem.upcast())))

[scampi]

The following method allows a binary operator to go multiline:
https://github.com/rust-lang-nursery/rustfmt/blob/e2b9c66cc9d3228339d07cb5410f6cabdac97de8/src/pairs.rs#L60-L62

Out of curiosity, I have made the following condition in that method return None so that it fails if it tries to put a multiline branch:
https://github.com/rust-lang-nursery/rustfmt/blob/e2b9c66cc9d3228339d07cb5410f6cabdac97de8/src/pairs.rs#L98

The result is the following formatting:

    disallowed_headers.iter().any(|header| *header == name)
        || disallowed_header_prefixes
            .iter()
            .any(|prefix| name.starts_with(prefix))

The 2nd branch went multiline because it didn't have enough allocated width (since it was to be placed after the first branch on the same line). With that other formatting, the 2nd branch would fit on a single line.

[topecongiro]

IMHO the second approach is better, though it still looks clunky because of the || at the front of the chain. Putting binary operators at the front doesn't really work well with block-indent + multi-line chain.

[nrc]

Putting binary operators at the front doesn't really work well with block-indent + multi-line chain.

Hmm, I think I don't mind this - I'm getting used to seeing binops at the front of lines and therefore this doesn't look too out of place to me.

[nrc]

I'm thinking of exactly how to formulate the condition here. "If the second sub-expr in a binop expr is multiline, always format it starting on a newline"? Or "... attempt to format on a newline and use the second formatting if it is single line, otherwise the first formatting"? I don't think there is any other way to split it.

[nrc]

Looking at the changes with @scampi 's suggestion, the changes which look much better with the current special case are those where the lhs is very short. I'm not sure exactly how to tweak this - maybe the tab width (since we use that elsewhere, although in this case we don't actually indent the second line) or maybe some custom heuristic (though I am not keen on adding more of these).

[nrc]

And note that in the OP, the chain is put on multiple lines because it is longer than the chain heuristic value, so the only question is whether `|| disallowed_header_prefixes`` should be on the first line or the second.