contradictory suggestion for labeled break with an unsafe block

[folkertdev]

Code

unsafe fn foo() {}

fn bar() {
    'blk: {
        match true {
            true => break 'blk unsafe { foo() },
            false => break 'blk (unsafe { foo() }),
        }
    }
}

Current output

warning: this labeled break expression is easy to confuse with an unlabeled break with a labeled value expression
 --> src/lib.rs:6:21
  |
6 |             true => break 'blk unsafe { foo() },
  |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(break_with_label_and_loop)]` on by default
help: wrap this expression in parentheses
  |
6 |             true => break 'blk (unsafe { foo() }),
  |                                +                +

warning: unnecessary parentheses around `break` value
 --> src/lib.rs:7:33
  |
7 |             false => break 'blk (unsafe { foo() }),
  |                                 ^                ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
7 -             false => break 'blk (unsafe { foo() }),
7 +             false => break 'blk unsafe { foo() },
  |

Desired output

// kind of unclear whether the one or the other should win. In any case, not both.

Rationale and extra context

In the example, both match branches have contradictory suggestions: the top branch suggests to add parentheses around the unsafe { ... }, while the bottom branch suggests to remove the unnecessary parentheses.

My intuition is that only vanilla blocks should trigger the lint in this postion, and that for unsafe it is sufficiently clear what the code does. e.g. this is invalid blk: unsafe { /* ... */ } so there is no ambiguity.

There is also not a loop in sight in my example, which also suggests that this lint is misapplied here.

A const { } expression only reports the unnecessary parens error.

Other cases

Rust Version

rustc 1.89.0-nightly (ccf3198de 2025-06-05)
binary: rustc
commit-hash: ccf3198de316b488ee17441935182e9d5292b4d3
commit-date: 2025-06-05
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.5

Anything else?

No response

[folkertdev]

This is fixed on nightly, by #137454