semicolon_if_nothing_return interacts unfortunately with rustfmt in match block

Description

In a match block, rustfmt automatically switches between => expr, and => { expr } forms in either direction, depending on the line length:

fn do_something() {}
…
    match input {
        "short pattern" => do_something(),
        "very long pattern that increases the line length beyond the rustfmt limit" => {
            do_something()
        }
        _ => {}
    }

However, the second form triggers Clippy’s pedantic semicolon_if_nothing_return lint.

It’s unfortunate that rustfmt can cause a new lint to be triggered (for users of clippy::pedantic). It’s also unfortunate that if we follow its suggestion and add a semicolon, rustfmt will no longer be able to collapse it to the first form if the length later decreases.

        "previously long pattern" => {
            do_something();
        }

Perhaps semicolon_if_nothing_return should exempt single-statement match cases for this reason?

Version

rustc 1.67.0-nightly (a28f3c88e 2022-11-20)
binary: rustc
commit-hash: a28f3c88e50a77bc2a91889241248c4543854e61
commit-date: 2022-11-20
host: x86_64-unknown-linux-gnu
release: 1.67.0-nightly
LLVM version: 15.0.4

Additional Labels

No response

Start with the semicolon_if_nothing_return lint and reproduce the match-block example alongside rustfmt's formatting behavior. Determine how single-statement match arms are handled, then verify that the chosen behavior avoids a new lint without preventing rustfmt from switching between the two forms.