Multi-line expression after => does not get braces

[RalfJung]

In some cases, a multi-line expression in a match arm does not get braces, violating the spec.

This leads to code like this:

pat => fun(
    a,
    b,
    c,
    d,
)

We also don't generate code like this:

if foo { fun(
    a,
    b,
    c,
    d,
)}

so it seems odd to do that for match arms.

[topecongiro]

the spec

TBH, I am not aware of that spec, and afraid that rustfmt may differ from it in multiple places.

The actual specification of rustfmt has been loosely defined in https://github.com/rust-dev-tools/fmt-rfcs. With respect to a multi-line expression on a match arm, rustfmt occasionally prefers to put it on the same line as => (cc https://github.com/rust-dev-tools/fmt-rfcs/blob/master/guide/expressions.md#match).

[varkor]

The actual specification of rustfmt has been loosely defined in rust-dev-tools/fmt-rfcs.

That spec also mandates blocks for multi-line expressions:

If the right-hand side consists of multiple statements or has line comments or the start of the line cannot be fit on the same line as the left-hand side, use a block.

[RalfJung]

That spec however also says

If the body is a single expression with no line comments and not a control flow expression, then it may be started on the same line as the right-hand side. If not, then it must be in a block.

The following example then explicitly asks for the formatting that I think is bad. It also talks about "combinable" expressions, I have no idea what that is.

[branpk]

Note that "control flow expression" doesn't include match expressions. So rustfmt does this:

match xopt {
    Some(x) => match yopt {
        Some(y) => {
            stmt1;
            stmt2;
        }
        None => {}
    },
    None => {}
}

If I later want to add a statement before or after the inner match statement, I have to manually insert braces around the match, which is a particularly confusing editing task when the inner match is large.

I don't feel strongly about the function call case, but I'd vote for at least counting match as a control flow expression.