[pbkx]

Fixes #116536.

The unused_braces lint could suggest removing braces from wildcard assignments like:

_ = { e };

producing:

_ = e;

These are not equivalent: _ = { e }; moves/drops e, while _ = e; does not. This PR suppresses unused_braces for assignment RHS blocks when the assignment LHS contains _.

ui regression test covers both the simple wildcard assignment case and a tuple destructuring assignment case

[rustbot]

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 21 candidates

[TaKO8Ki]

Thank you. I left one comment.

View changes since this review

[TaKO8Ki]

I think this lint should not be triggered in some other cases like (..) = { e } [..] = { e }. Can we address them here as well?

#![deny(unused_braces)]

struct D(&'static str);

impl Drop for D {
    fn drop(&mut self) {
        println!("drop {}", self.0);
    }
}

fn main() {
    let e = (D("a"), D("b"));
    (..) = { e };
}

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[pbkx]

@rustbot ready

[pbkx]

@TaKO8Ki

[fmease]

That's too coarse. Consider:

fn main() {
    let e = String::new();
    _ = { (e,) };
}

The braces are indeed unnecessary because the tuple construction (_,) already moves/drops e regardless of whether there are any { }. But now under your PR we no longer lint here.

The tuple construction is just an example.

Should at least be a FIXME. Not sure if it's worth blocking this PR on fixing this new class of false negatives...

View changes since the review