fix: semicolon_inside_block don't eat closing paren in ({0});

[ada4a]

depends on #15390, but not critically

changelog: [semicolon_inside_block] don't eat closing paren in ({0});

fixes #15380

PS: this is almost identical to #15386 -- I wonder if there's a better way of doing this, given that pretty much anything in Rust can be wrapped in (an arbitrary number of) parens without change of meaning

[rustbot]

r? @samueltardieu

rustbot has assigned @samueltardieu.
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

[breandead]

i wonder if it would not be better to not emit the suggestion at all when we have a block inside open brackets, that avoids the issues with making a statement into an expression; I don't think it makes much sense to drag the semicolon through the brackets, as the lints description is written in the docs it shouldnt do it imo

[ada4a]

That does sound sensible. Although it still won't fix #15388, since that happens even without parens

[ada4a]

oh and I think this comment might actually be wrong because of this?

rust-clippy/clippy_lints/src/semicolon_block.rs

Lines 107 to 109 in 5930e54

	// For macro call semicolon statements (`mac!();`), the statement's span does not actually
	// include the semicolon itself, so use `mac_call_stmt_semi_span`, which finds the semicolon
	// based on a source snippet.

[ada4a]

closed in favor of #15421