Precedence improvements: closures and jumps

[dtolnay]

This PR fixes some cases where rustc's pretty printers would redundantly parenthesize expressions that didn't need it.

Before	After
return (|x: i32| x)	return |x: i32| x
(|| -> &mut () { std::process::abort() }).clone()	|| -> &mut () { std::process::abort() }.clone()
(continue) + 1	continue + 1

Tested by echo "fn main() { let _ = $AFTER; }" | rustc -Zunpretty=expanded /dev/stdin.

The pretty-printer aims to render the syntax tree as it actually exists in rustc, as faithfully as possible, in Rust syntax. It can insert parentheses where forced by Rust's grammar in order to preserve the meaning of a macro-generated syntax tree, for example in the case of a * $rhs where $rhs is b + c. But for any expression parsed from source code, without a macro involved, there should never be a reason for inserting additional parentheses not present in the original.

For closures and jumps (return, break, continue, yield, do yeet, become) the unneeded parentheses came from the precedence of some of these expressions being misidentified. In the same order as the table above:

• Jumps and closures are supposed to have equal precedence. The Rust Reference says so, and in Syn they do. There is no Rust syntax that would require making a precedence distinction between jumps and closures. But in rustc these were previously 2 distinct levels with the closure being lower, hence the parentheses around a closure inside a jump (but not a jump inside a closure).

• When a closure is written with an explicit return type, the grammar requires that the closure body consists of exactly one block expression, not any other arbitrary expression as usual for closures. Parsing of the closure body does not continue after the block expression. So in || { 0 }.clone() the clone is inside the closure body and applies to { 0 }, whereas in || -> _ { 0 }.clone() the clone is outside and applies to the closure as a whole.

• Continue never needs parentheses. It was previously marked as having the lowest possible precedence but it should have been the highest, next to paths and loops and function calls, not next to jumps.

[rustbot]

r? @spastorino

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

[spastorino]

Sorry that it took very long for me to get into this. I think this is good and makes sense in general and the code looks perfect.
Not sure if lang or any other team need to have a say or something around this cc @traviscross

[dtolnay]

This is my 40th pretty-printer change and they have not needed a full team review. There is no stable or irreversible commitment being made. See similar parenthesization PRs in #118726 and #119105 and #119427.

[traviscross]

This all sounds right to me. Agreed there's nothing lang needs to rule on here (but it is interesting work, so cc @rust-lang/lang).

cc @compiler-errors

[traviscross]

@bors r=spastorino,traviscross rollup

[bors]

📌 Commit fe06c5d has been approved by spastorino,traviscross

It is now in the queue for this repository.