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